Не знаю как вы, но я писала пост о защите детей от информации, а не об истреблении убийц.

В такой постановке тема вообще не имеет смысла. Мы что же, обсуждаем абстрактный метод, без конечной цели?

Все верно. Эти люди видели не интернет, а насилие, алкоголь, наркотики и секс на улице, дома, в школе. И корреляция по всем перечисленным мною пунктам. В том то и дело, что сейчас ко всему прочему можно увидеть это же в интернете, причем вас не спасет ни благоприятный район, ни элитная школа (если раньше они могли снизить риск).

То есть вы таки искренне считаете, что закладывающий за воротник отец, который каждый день лупит выпивающую мать, друзья, нюхающие клей и т.д. и т.п. — это то же самое, что посмортеть в ютубе ролик, где плохой терминатор убивает хорошего?

Разумеется, если отфильтровывать неугодный контент, то насильники, убийцы и суицидники никуда не денутся (ведь именно этого мы добиваемся, верно?). Статистика тоже не изменится (есть теория, что может изменится в худшую сторону).
Конечно, случается, когда ребята, переигравши в Дум продолжают игру в реале. Но это — единичные исключения, известные всему миру. Посмотрите статистику — кто у нас проходит по самым тяжким преступлениям? Сколько из этих людей видело в глаза компьютеры с интернетами? Какие мультики они смотрели — правильные (про чебурашку) или неправильные (про микки-мауса)? Нелепо. Видели они совершенно другие картинки из реальной жизни, которых никто из здесь сидящих, к счастью, не сможет представить даже близко. Попробуйте обратиться с запросом в соотв. органы (конечно вряд ли ответят), пусть они вам опишут портрет современного злодея, и вы убедитесь, что никакой корреляции, ни по одному описанному вами пункту, не существует.
Остальное не стоит обсуждения (из серии — дать по шее, забрать пульт и уложить спать).

Результаты обновлены.

как именно мне сделать так, чтобы это ядро не было занято вообще ничем кроме ноды. Вот это было бы здорово!

isolcpus

На остальное скажу одно: в моем бенче выявлены грубые нарушения (в т.ч. и вами, но дело тут не только и не столько в affinity, сколько в общем макс. количестве потоков сервера\клиента на N-ядерном процессоре), в ближайшие дни часть «результаты» будет полностью переделана.

Пока все в процессе, но первые (грубые) результаты по вашей методике (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, понять вашу идею.

Не происходит ли Jit-компиляция единожды, в момент запуска скрипта?

Как автор «той» статьи, не могу пройти мимо.

— 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 и т.п.

К сожалению, gwan очень сильно завязан на linux — окружение. Было бы интересно узнать, что представляет из себя этот выделяющийся на фоне остальных серверов своей весьма агрессивной рекламой сервер.

Из того, что я про него читал здесь (раздел How is it so fast?), в node.js нет оверхедов на JIT-компиляцию и виртуальная машина не вовлечена в процесс, незнаю насколько это соотвествует действительности.
На практике помню, что GC практически полностью парализовывал работу сервера.

Утилита от создателя дисквалифицированного nxweb. По заявлению автора — Inspired by weighttp tool, синтаксис ком. строки полностью совпадает.
Компиляция осложнена linux-зависимостями типа sys/sendfile и memalign (патчится легко).
При запуске выкидывает кучу ошибок соединения, потом тесты проходят, результат аналогичен weighttp.
Других различий не обнаружил.

Вы правы, для onion в FreeBSD механизм событий при сборке по-умолчанию — libev.
poco (из портов) — в FreeBSD использует select.