Пока все в процессе, но первые (грубые) результаты по вашей методике (1 серв. процесс с афинити, 4 потока клиента с аффинити) аналогичны результатам из моих первоначальных тестов (там ведь тоже были режимы с 1 серв. процессом). nginx в этом режиме опережает остальных топовых участников в 2.5 раза. Ваш комментарий по этому поводу, как разработчика nginx?
Кстати, wrk показал 1-3% прирост по сравнению с weighttp. Подробные результаты будут позже…
Т.е. на моей конфигурации (8 физических ядер) достаточно будет 1 рабочего процесса (с заданным аффинити), 4 потока клиента (3 ядра остается системе), 30-100 измерений по 30-120 секунд. Ок, прогоню такие тесты с weighttp и wrk, результаты предоставлю.
Перегнал тесты по nginx с worker_processes = 8 и выключенным AMD Turbo Core и Cool'n'Quiet.
Результаты — минус 1-2 процента производительности почти по всем итерациям (макс. результат — 136485, упал до 135620 (-0.6%).
Утверждение о влиянии AMD Turbo Core выглядит сомнительным.
К вопросу о тестировании на разных машинах — какие модели сетевых карт были бы приняты за достоверно отображающие производительность? Например, подходит ли для адекватного тестирования Broadcom BCM57780? Realtek RTL8139? Что можете сказать о свиче?
ну нету в FreeBSD файла sys/sendfile.h :) (и нигде нет, кроме linux).
Это все про общую «небрежность» кода, что заставляет задуматься об использования этой тулзы в любых тестах.
Почитал про affinity в linux. Выяснилось, что сложность планировщика при переключении задач между ядрами CPU в 2.6 ядре составляет аж O(1). Кроме того, без isolcpus то что вы пытаетесь делать вообще лишено смысла. Окончательную точку может поставить только эксперимент, но для этого мне нужно понять как именно вы пытаетесь сыграть с taskset, понять вашу идею.
— NGINX отдаёт только свою дефолтную статическую страницу index.html.
— Сервер Node должен вести подсчёт соединений и выдавать в каждом ответе результат, так же считать и максимальное количество.
Вы выставляете неравные условия участникам. Допустим, в nginx и ОС не реализовано кеширование файлов. Тогда nginx заведомо бежит с гирей на ноге.
Почему бы Node тоже не отдавать файл? Пока непонятно, почему именно такая постановка задачи.
Сразу скажу, что все тесты я крутил минут по 10, занимаясь при этом обычными задачами типа кода и сёрфинга.
Ой, это зря. Хотя вы упоминали что пишите только на JS (т.е. надеюсь не было компиляций С++ кода и прочих убийц CPU в процессе тестирования).
ПО для запросов я тоже написал на ноде через request.js.
Хм, а вы уверены что ваше ПО для запросов способно физически выдать больше запросов/сек, чем показал ответов nginx :)?
Покажите результаты с weighttp.
С аффинити я вообще ничего не понял если честно. Т.е. понятно, что вы тестили с вызовом taskset -pc и без него и в этом суть ваших измерений, но результаты осмыслить не смог. С вашего позволения, прогоню тесты у себя, скажите что ставить в аффинити и какой из скриптов брать (test_httpserver.js или overload.js)?
В системе настройки не менялись, они не давали прироста производительности (см. параграф под настройками в статье).
Какой утилитой тестили python сервер?
sendfile
Not specified in POSIX.1-2001, or other standards.
Other UNIX systems implement sendfile() with different semantics and prototypes. It should not be used in portable programs.
В данной утилите он не нужен, но он там почему-то есть.
Признаться — была такая мысль, но как-то не попалось готового модуля, который можно быстро переделать под нужды тестирования (все больше какие-то пространые мануалы с вовлечением apxs и прочих ужасных вещей). Та же участь постигла lighttpd. Но это, я думаю, и не страшно — тут тестируются C/C++ библиотеки/фреймворки, nginx и node.js приведены лишь для сравнения с миром «готовых» HTTP-серверов. А так да — в черновиках была целая простыня из mongrel, cherokee и т.п.
Спорный вопрос, смотря какие стоят цели и задачи. Если это нагрузочный прогон системы перед запуском в продакшн — то однозначно localhost не подходит. Если же это тестирования сферических ядер на лабораторном стенде — localhost вполне жизнеспособное решение. одно из мнений «за» (раздел Why localhost tests are relevant?)
К сожалению, gwan очень сильно завязан на linux — окружение. Было бы интересно узнать, что представляет из себя этот выделяющийся на фоне остальных серверов своей весьма агрессивной рекламой сервер.
Из того, что я про него читал здесь (раздел How is it so fast?), в node.js нет оверхедов на JIT-компиляцию и виртуальная машина не вовлечена в процесс, незнаю насколько это соотвествует действительности.
На практике помню, что GC практически полностью парализовывал работу сервера.
Утилита от создателя дисквалифицированного nxweb. По заявлению автора — Inspired by weighttp tool, синтаксис ком. строки полностью совпадает.
Компиляция осложнена linux-зависимостями типа sys/sendfile и memalign (патчится легко).
При запуске выкидывает кучу ошибок соединения, потом тесты проходят, результат аналогичен weighttp.
Других различий не обнаружил.
Контроль за ресурсы — по сути все сервера находятся в одинаково невыгодном положении, надеялся компенсировать это результатами, построенными на многократных запусках (более ста итераций на каждый сервер). Но согласен — это один из самых спорных моментов в данной статье. Никогда не слышал про Turbo Core 2, еще раз убеждаюсь, что идеальных бенчмарков не бывает, слишком много влияющих параметров.
Колонки «Время(польз.\сист.)» в таблице результатов — это psutil get_cpu_times() для родительского и дочерних процессов сервера.
Память не мерялась в силу того, что ни один участник не использовал этот ресурс сколько-нибудь значительно (кроме node.js, о чем есть упоминание).
Кстати, wrk показал 1-3% прирост по сравнению с weighttp. Подробные результаты будут позже…
Результаты — минус 1-2 процента производительности почти по всем итерациям (макс. результат — 136485, упал до 135620 (-0.6%).
Утверждение о влиянии AMD Turbo Core выглядит сомнительным.
К вопросу о тестировании на разных машинах — какие модели сетевых карт были бы приняты за достоверно отображающие производительность? Например, подходит ли для адекватного тестирования Broadcom BCM57780? Realtek RTL8139? Что можете сказать о свиче?
Это все про общую «небрежность» кода, что заставляет задуматься об использования этой тулзы в любых тестах.
Вы выставляете неравные условия участникам. Допустим, в nginx и ОС не реализовано кеширование файлов. Тогда nginx заведомо бежит с гирей на ноге.
Почему бы Node тоже не отдавать файл? Пока непонятно, почему именно такая постановка задачи.
Ой, это зря. Хотя вы упоминали что пишите только на JS (т.е. надеюсь не было компиляций С++ кода и прочих убийц CPU в процессе тестирования).
Хм, а вы уверены что ваше ПО для запросов способно физически выдать больше запросов/сек, чем показал ответов nginx :)?
Покажите результаты с weighttp.
С аффинити я вообще ничего не понял если честно. Т.е. понятно, что вы тестили с вызовом taskset -pc и без него и в этом суть ваших измерений, но результаты осмыслить не смог. С вашего позволения, прогоню тесты у себя, скажите что ставить в аффинити и какой из скриптов брать (test_httpserver.js или overload.js)?
Какой утилитой тестили python сервер?
Not specified in POSIX.1-2001, or other standards.
Other UNIX systems implement sendfile() with different semantics and prototypes. It should not be used in portable programs.
В данной утилите он не нужен, но он там почему-то есть.
одно из мнений «за» (раздел Why localhost tests are relevant?)
На практике помню, что GC практически полностью парализовывал работу сервера.
Компиляция осложнена linux-зависимостями типа sys/sendfile и memalign (патчится легко).
При запуске выкидывает кучу ошибок соединения, потом тесты проходят, результат аналогичен weighttp.
Других различий не обнаружил.
poco (из портов) — в FreeBSD использует select.
Память не мерялась в силу того, что ни один участник не использовал этот ресурс сколько-нибудь значительно (кроме node.js, о чем есть упоминание).