В легковесности — их можно создавать быстро и много.
В качестве отправной точки для значения worker_processes документация предлагает использовать количество ядер.
Вот есть у нас 16 ядер, и, соответственно 16 воркеров. И заняты он тем, что все жмут gzip-ом большие HTML-страницы — ну очень процессороёмкая операция. Приходит новое соединение с запросом на маленькую картинку. Оно принимается мастер-процессом (или откладывается в очередь) и ждёт, пока освободится воркер. А ведь ресурсов, чтобы его отдать прямо сейчас, практически не нужно.
Когда ядро раскладывает соединения, оно не знает, в каком из них будет легкий запрос, а в каком тяжелый
Собственно nginx тоже не знает, каким будет соединение, и какие запросы потом ещё придут.
итоге один воркер может получить много легких запросов и быстро с ними справиться, обслужит всю свою очередь соединений на своем дескрипторе, а затем будет простаивать
Простаивать точно не будет, так как запросы на сервер продолжают поступать (если это не бенчмарк).
Так что я думаю, что на момент accept()-а соединения, что у ядра, что у nginx-а примерно одинаковые возможности по балансировке — по загрузке процессора.
Если бы nginx поддерживал потоки, ситуация с равномерностью загрузки была бы красивее.
Смеялся до слёз… Кто не открывал тот талмуд на 5287 страниц, тому не понять :)
На самом деле я не думаю, что многие возьмутся проектировать систему с нуля. Freescale даёт несколько базовых шаблонов Sabre-(lite|sd|hdmidongle) на основе которых и допиливаются нужные дизайны.
Отличные платы. На их базе можно собирать полноценные сервера. Жаль только цен ещё не видно.
И кстати интересно, вот этот самый Freescale i.MX6Q, появился относительно давно, а разные интересные устройства только начинают появляться. Распробовали и вошли во вкус?
Снял немного циферок. За неделю в среднем в день (по /proc/diskstats) на диск записывается 317GB, т.е. диск объёмом 32GB перезаписывается ~10раз. Если ресурс 5тыс, то должно хватать на 500 дней, по факту меньше. Видимо write amplification сказывается. Хотя контроллер SandForce, и данные, теоретически, должны хорошо ужиматься.
Я себе лично заказывал на рабочий адрес, и проблемы были — требовали документов на юр. лицо, внешнеэкономическая деятельность, сертификация и т.п. И всё потому, что в адресе было указано ООО. Поэтому если указываете рабочий адрес, не пишите названия организации ни в каком виде.
если с утра позанимался, то боль в мышцах при, например, перемещении руки с клавы на мышку мешает сосредоточиться
При нерегулярных занятиях так и будет. Врачи вообще не рекомендуют давать рандомные нагрузки, вредно очень. Зато когда втянешься (обычно две недели), то потом уже без утренней пробежки руки не смогут с клавы на мышку перемещаться, а все мысли будут о том, как бы пробежаться. Как наркотик, втягивает, честно.
Глаза боятся — ноги крутят :)
Из защиты — обязательный шлем ну и перчатки. Влёт в люк/яму на скорости свыше 30 конечно чреват травмами, поэтому быстро езжу только на проверенных участках.
Наверняка где-то у себя отмечают, чтобы на следующий раз сильнее перетряхивать вещи. А так — обычное административное правонарушение, такое же как парковка в неположенном месте.
таможня запросто может назначить свою стоимость товара и заставить платить 30% его стоимости
Бывает и хуже. Вёз старое барахло после апгрейда, в том числе 6 винтов (Maxtor 200GB SATA), которые простояли на сервере 5 лет. Наши (украинские) таможенники сняли меня с поезда, «товар» изъяли. Потом 3 поездки в суд (из Киева в Глухов). Винты «экспертиза» оценила как новые, причём по цене брали явно как SSD. В итоге я оплачиваю экспертизу, растаможку, штраф и получаю почётное звание контрабандиста.
К тому же бег, как и любые другие упражнения, сильно повышает самооценку — ты поборол свою лень, ты любишь своё тело, ты молодец!
Это чертовски важно, это мотивирует!
Я по-быстрому потестил на дефолтном конфиге с разницей только во включенном или выключенном so_reuseport.
До 2-х тысяч одновременных соединений — быстрее без so_reuseport, свыше (проверял вплоть до 20-ти тысяч) — уже быстрее с so_reuseport, на ~10%.
В качестве отправной точки для значения worker_processes документация предлагает использовать количество ядер.
Вот есть у нас 16 ядер, и, соответственно 16 воркеров. И заняты он тем, что все жмут gzip-ом большие HTML-страницы — ну очень процессороёмкая операция. Приходит новое соединение с запросом на маленькую картинку. Оно принимается мастер-процессом (или откладывается в очередь) и ждёт, пока освободится воркер. А ведь ресурсов, чтобы его отдать прямо сейчас, практически не нужно.
Простаивать точно не будет, так как запросы на сервер продолжают поступать (если это не бенчмарк).
Так что я думаю, что на момент accept()-а соединения, что у ядра, что у nginx-а примерно одинаковые возможности по балансировке — по загрузке процессора.
Если бы nginx поддерживал потоки, ситуация с равномерностью загрузки была бы красивее.
На самом деле я не думаю, что многие возьмутся проектировать систему с нуля. Freescale даёт несколько базовых шаблонов Sabre-(lite|sd|hdmidongle) на основе которых и допиливаются нужные дизайны.
И кстати интересно, вот этот самый Freescale i.MX6Q, появился относительно давно, а разные интересные устройства только начинают появляться. Распробовали и вошли во вкус?
Из защиты — обязательный шлем ну и перчатки. Влёт в люк/яму на скорости свыше 30 конечно чреват травмами, поэтому быстро езжу только на проверенных участках.
Предлагаю обсудить
Это чертовски важно, это мотивирует!
C включенным so_reuseport — 3723 req/s
Без патча — 2933 и 3117 req/s (accept_mutex off/on)
Таким образом по положению звёзд тоже можно ориентироваться. Хотя бы направление понять. :)
so_reuseport off;
Requests per second: 3342
accept_mutex off;
so_reuseport off;
Requests per second: 3307
accept_mutex off;
so_reuseport on;
Requests per second: 3874
ab -c 20000
среднее 4-х итераций
Intel Atom D525 :)
До 2-х тысяч одновременных соединений — быстрее без so_reuseport, свыше (проверял вплоть до 20-ти тысяч) — уже быстрее с so_reuseport, на ~10%.
Под наш любимый nginx тоже патчики есть. Прирост весьма существенный.