tag:blogger.com,1999:blog-3767932718256497924.post8263472374514844..comments2023-04-11T13:54:51.547+03:00Comments on asio samples: Уязвимости серверов к медленному чтениюMarat Abrarovhttp://www.blogger.com/profile/01714473137005987457noreply@blogger.comBlogger13125tag:blogger.com,1999:blog-3767932718256497924.post-38198406695030579802012-08-11T00:03:35.271+04:002012-08-11T00:03:35.271+04:00Забыл указать в предыдущем комментарии - это резул...Забыл указать в предыдущем комментарии - это результаты echo_server.Marat Abrarovhttps://www.blogger.com/profile/01714473137005987457noreply@blogger.comtag:blogger.com,1999:blog-3767932718256497924.post-36507533131763317752012-08-11T00:00:34.708+04:002012-08-11T00:00:34.708+04:00Кстати, вот что получилось у меня на Windows (Inte...Кстати, <a href="https://docs.google.com/open?id=0B4NhcxJYpyXGRGd4akZqV05oX2s" rel="nofollow">вот что</a> получилось у меня на Windows (Intel Core2 Duo E7200, клиент по сети).Marat Abrarovhttps://www.blogger.com/profile/01714473137005987457noreply@blogger.comtag:blogger.com,1999:blog-3767932718256497924.post-54156794411527830742012-07-24T10:32:51.277+04:002012-07-24T10:32:51.277+04:00Посмотрел заодно Boost.Thread и обнаружил следующе...Посмотрел заодно Boost.Thread и обнаружил следующее:<br />1. boost::mutex под Windows использует spinlock + Windows event, что очень похоже на обычную критическую секцию Windows, но позволяет делать timed-блокировки.<br />2. boost::mutex под Linux использует только POSIX Threads mutex, что в купе со статьями навроде <a href="http://www.alexonlinux.com/pthread-mutex-vs-pthread-spinlock" rel="nofollow">этой</a> вызывает недоумение.Marat Abrarovhttps://www.blogger.com/profile/01714473137005987457noreply@blogger.comtag:blogger.com,1999:blog-3767932718256497924.post-62491525167373878202012-07-24T09:38:25.514+04:002012-07-24T09:38:25.514+04:00Добавлю: в Asio под Linux в качестве мьютекса испо...Добавлю: в Asio под Linux в качестве мьютекса используется класс boost::asio::detail::posix_mutex (boost_1_50_0\boost\asio\detail\posix_mutex.hpp). В то же время, под Windows используется критическая секция (boost_1_50_0\boost\asio\detail\win_mutex.hpp).<br /><br />Не знаю как в POSIX Threads, но критическая секция Windows помимо мьютекса содержит в себе spin lock, который не дает работать с реальным мьютексом Windows пока кол-во итераций на spin lock не достигнет определенного барьера. Полагаю, это (вместе с IOCP с его специализированной процедурой планирования потоков) позволяет Asio под Windows избавиться от того громадного кол-ва переключений контекстов потоков, что я наблюдаю в http://i038.radikal.ru/1207/50/a317e304fcd2.png.Marat Abrarovhttps://www.blogger.com/profile/01714473137005987457noreply@blogger.comtag:blogger.com,1999:blog-3767932718256497924.post-79606711929456888582012-07-24T09:18:14.080+04:002012-07-24T09:18:14.080+04:00На первый взгляд есть проблема с клиентом asio-sam...<i>На первый взгляд есть проблема с клиентом asio-samples заключающаяся в недостаточном распараллеливании. Возможно виноват asio::strand.</i><br /><br />Возьмите обновленный вариант из https://asio-samples.svn.sourceforge.net/svnroot/asio-samples/trunk. Есть надежда, что виноват вызов конструктора asio::io_service без указания <a href="http://www.boost.org/doc/libs/1_50_0/doc/html/boost_asio/reference/io_service/io_service/overload2.html" rel="nofollow">concurrency_hint</a>.<br /><br />Я же тем временем <a href="http://asio-samples.blogspot.com/2012/07/asio-performance-test.html" rel="nofollow">смотрю</a>, что творится с echo_server и asio_performance_test_client под Windows. И, насколько я пока могу судить, там все хорошо и ожидаемо.Marat Abrarovhttps://www.blogger.com/profile/01714473137005987457noreply@blogger.comtag:blogger.com,1999:blog-3767932718256497924.post-91371553162995933962012-07-17T23:46:03.809+04:002012-07-17T23:46:03.809+04:00Попрофилировал сегодня с помощью Intel VTune. Завт...Попрофилировал сегодня с помощью Intel VTune. Завтра еще продолжу.<br /><br />На первый взгляд есть проблема с клиентом asio-samples заключающаяся в недостаточном распараллеливании. Возможно виноват asio::strand.<br /><br />Анализ (overview) выполнения клиента из asio samples: <br />http://i081.radikal.ru/1207/72/38915064a525.png<br /><br />http://i038.radikal.ru/1207/50/a317e304fcd2.png<br /><br />И, для сравнения, клиента из github:<br />http://i024.radikal.ru/1207/b4/66195a49f1c5.png<br /><br />http://s019.radikal.ru/i610/1207/d3/7140349ebaa2.png<br /><br />Сравнить работу echo серверов пока не успел.Anonymoushttps://www.blogger.com/profile/17410290304367876610noreply@blogger.comtag:blogger.com,1999:blog-3767932718256497924.post-57593008185788714742012-07-16T22:00:10.226+04:002012-07-16T22:00:10.226+04:00Открыть >64k сессий между двумя машинами неслож...Открыть >64k сессий между двумя машинами несложно. Для этого надо назначить на сервере несколько ip адресов на сетевой интерфейс, а с клиента коннектится на них по-очереди.<br /><br />Но в данном случае я ошибся, речь идет о 10k сессий.<br /><br />Торомозит - это значит недозагружает эхо сервер.<br /><br />Я сейчас взял пару серверов E5645 c 12 физ. ядрами, с HT всего 24 логических ядер. Соединены сетью напрямую. На одной запущен эхо сервер, на другой пускаю разные клиенты.<br /><br />Клиент из github открывает 10k сессий к серверу, отправляет по ним сообщения по 32байта, принимает, сравнивает. <br /><br />За минуту работы он у меня показывает типично 40-45 млн успешно принятных сообщения. Т.е. получается 1280-1440 MByte в минуту.<br /><br />При этом на машине с echo сервером возникает суммарная загрузка процессоров <br />User: 8.5%, System: 35%, I/O: 16.5%, Idle: 40%<br /><br />На машине с клиентом:<br />User: 16.5, System: 59%, I/O: 20%, Idle: 4.5%<br /><br />Запускаю твой клиент <br />asio_performance_test_client 10.0.0.2 32000 24 32 100 60<br /><br />он выдает <br />275390944 total bytes written<br />275389520 total bytes read<br /><br />Загрузка машины с эхо сервером - <br />User: 4%, System: 16%, I/O: 2%, Idle: 78%.<br /><br />На клиенте:<br />User: 14%, System: 75%, I/O: 10%, Idle: 1%.<br /><br />До профилирования я пока не добрался.<br /><br />Сервер соединения не рвет, насколько я могу судить. Сетевых ошибок вообще не возникает.Anonymoushttps://www.blogger.com/profile/17410290304367876610noreply@blogger.comtag:blogger.com,1999:blog-3767932718256497924.post-6682090556695793612012-07-16T19:07:12.207+04:002012-07-16T19:07:12.207+04:00Попробовал asio_performance_test_client, на большо...<i>Попробовал asio_performance_test_client, на большом количестве сессий (100к) он тормозит.</i><br /><br />Одновременно 100k исходящих TCP-соединений с одной машины - такое возможно (<a href="http://en.wikipedia.org/wiki/Ephemeral_port" rel="nofollow">ephemeral port</a>)? Попробуйте, хотя бы, 30k. Иначе, боюсь, все, что свыше определенного лимита, будет вхолостую отнимать время процессора на циклы async_accept -> handle_accept(some_error_related_to_resource_out).<br /><br />В чем выражаются тормоза?<br /><br /><i>При использовании клиента из github - загрузка значительно сильнее 65% (35% idle). Предполагаю, что из-за использования мутексов/локов вместо атомарных операций.</i><br /><br />Явная блокировка на мьютексе в asio_performance_test_client происходит лишь при закрытии TCP-соединения. Значит, либо сервер часто рвет соединения, либо тормозит asio::io_service::strand (там внутри тоже мьютекс), либо дело вовсе не в блокировках (частые переключения контекстов потоков?).<br /><br />Мне все больше хочется увидеть ваш отчет профилировщика. Попробую провести эксперимент на домашней машине с профилировщиком, встроенным в MS VS 2010 - горячие точки, полагаю, можно найти и так. Правда, это будет Windows-only.<br /><br />В любом случае, спасибо за информацию.Marat Abrarovhttps://www.blogger.com/profile/01714473137005987457noreply@blogger.comtag:blogger.com,1999:blog-3767932718256497924.post-45334427261190516082012-07-16T17:42:28.091+04:002012-07-16T17:42:28.091+04:00Попробовал asio_performance_test_client, на большо...Попробовал asio_performance_test_client, на большом количестве сессий (100к) он тормозит. <br /><br />На небольшом (100) показывает лучшие результаты, но в любом случае echo server с ним грузит машину на 10% (показывает 90% idle). При использовании клиента из github - загрузка значительно сильнее 65% (35% idle). <br /><br />Предполагаю, что из-за использования мутексов/локов вместо атомарных операций.<br /><br />С остальным пока продолжаю разбираться.Anonymoushttps://www.blogger.com/profile/17410290304367876610noreply@blogger.comtag:blogger.com,1999:blog-3767932718256497924.post-826489747112681362012-07-13T01:59:56.362+04:002012-07-13T01:59:56.362+04:00Исходники сервера: http://liveworkspace.org/code/9...Исходники сервера: http://liveworkspace.org/code/91a89b2fd2f894af13c6282e3ddde82f<br /><br />Код не академический, заранее извиняюсь.<br /><br />Смогу перетестировать и покопаться профайлером на следующей неделе.Anonymoushttps://www.blogger.com/profile/17410290304367876610noreply@blogger.comtag:blogger.com,1999:blog-3767932718256497924.post-27394550665350923322012-07-12T01:13:30.942+04:002012-07-12T01:13:30.942+04:00Но что странно, похоже что ни service-per-cpu, ни ...<i>Но что странно, похоже что ни service-per-cpu, ни handler allocator на этом тесте не влияют на производительность.</i><br /><br />Эх, еще бы результаты работы профилировщика глянуть.Marat Abrarovhttps://www.blogger.com/profile/01714473137005987457noreply@blogger.comtag:blogger.com,1999:blog-3767932718256497924.post-56589822379234441622012-07-12T01:07:58.691+04:002012-07-12T01:07:58.691+04:00По мотивам этой ветки: http://comments.gmane.org/g...<i>По мотивам этой ветки: http://comments.gmane.org/gmane.comp.lib.boost.asio.user/5133</i><br /><br />В той ветке, насколько я помню, сошлись в том, что Asio, возможно, неэффективно работает с epoll, что, в свою очередь, выливается в излишние переключения контекстов потоков.<br /><br /><i>Простой echo-server на ерланге уделывает echo server на asio.</i><br /><br />Хотелось бы глянуть на "echo server на asio".<br /><br /><i>И резервов догнать ерланг, как я понимаю, нет.</i><br /><br />Покажите результаты, пожалуйста.<br />Есть один нюанс, который стоит всегда помнить - custom handler allocator должен влиять на скорость выполнения операций ввода/вывода. И только. Создание новых экземпляров session при помощи ::new может быть узким местом сервера на Asio (по сравнению с Erlang). Т.е. в тесте стоит все же выделить результаты для собственно ввода/вывода на уже установленных соединениях.<br />Например, при тестировании echo_server из asio-samples, я устанавливаю заранее большое число recycled_sessions, после чего «прогреваю» echo_server созданием большого кол-ва одновременных сессий (да, echo_server пока просто не умеет преаллоцировать экземпляры session).<br /><br /><i>Тестировалось этим клиентом: https://github.com/virtan/mrps/tree/master/client-c++-virtan</i><br /><br />А asio_performance_test_client не пробовали? У меня упирается в пропускную способность сети (а запускать сервер и клиент на одной машине для теста бесполезно).Marat Abrarovhttps://www.blogger.com/profile/01714473137005987457noreply@blogger.comtag:blogger.com,1999:blog-3767932718256497924.post-52730683284410247862012-07-12T00:06:15.402+04:002012-07-12T00:06:15.402+04:00Вопрос не совсем по теме, но по производительности...Вопрос не совсем по теме, но по производительности.<br /><br />По мотивам этой ветки: http://comments.gmane.org/gmane.comp.lib.boost.asio.user/5133<br /><br />Простой echo-server на ерланге уделывает echo server на asio. <br /><br />Erlang сервер: https://github.com/virtan/mrps/tree/master/erlang-virtan<br /><br />Тестировалось этим клиентом: https://github.com/virtan/mrps/tree/master/client-c++-virtan<br /><br />на i7 2600 с 4 ядрами под linux и boost 1.50. Оценивалось количество успешно переданных/принятых сообщений с большим кол-вом сессий. На латентность не обращалось внимание.<br /><br />Попробовал накидать свой клиент, с использованием io_service per CPU и pthread_setaffinity и с custom handler allocator. Тексты выложу немного позже, если кому-нибудь интересно. <br /><br />Но что странно, похоже что ни service-per-cpu, ни handler allocator на этом тесте не влияют на производительность. Об этом же писал Christof Meerwald, в упомянутой ветке.<br /><br />И резервов догнать ерланг, как я понимаю, нет.Anonymoushttps://www.blogger.com/profile/17410290304367876610noreply@blogger.com