> Может треснет, а может и нет. Если бы вы поинтересовались количественной
> стороной дела, а не "мордами" - может и был бы толк... Меня "может" как-то не очень устраивает. Как ленивый админ я люблю работающие сервера и отсутствие у меня головняка. Даже в неидеальных ситуациях.
>> Машина состояний вообще ничего подобного таким не выделает.
> Не таким, так другим. И так и эдак - ресурсы растут,
> пропорционально числу обслуживаемых в данный момент клиентов.
Да, только одно дело если это 2.5М на 10 000 малоактивных соединений и другое если это несколько гигз. Разница на несколько порядков в том сколько клиентов на даденой конфиге оно удержит, сущие мелочи, право :).
Пионерия как раз успешно пользуется фактором усиления атаки, заваливая кучу здоровенных гробов чуть ли не с мобилок и нетбуков. Благодаря большой несимметрии по ресурсам на клиенте и сервере - можно даже так. Нжинкс на такое вообще не покупается - усиления атаки нет.
>> Куда более многообещаюшее поведение в случае множества медленных
>> клиентов/множественных параллельных соединений.
> Это может быть интересно и перспективно для конкретных проектов с высокой нагрузкой.
А также для нелюбителей тормозных сайтов, тех кто планирует обслуживать более нескольких юзерей, тех кто хочет спокойно спать а не слушать жалобы что сайт умер от пионерддоса с мобилки и прочая.
> Не ленящихся переписать движок сайта, или написать модуль для nginx
> под проект. Или ориентированных на раздачу статики.
Можно и не переписывать. Работать будет. Просто свойствами того же фастцги или модулей нжинкса можно воспользоваться более оптимально по ресурсам, если это стало надо.
> Но когда nginx позиционируют как "универсальную замену" apache - это глупо.
Так поэтому то fastcgi и прочая и не являются костылем, как вы пытались это представить. Это как раз интерфейс к серверу приложений. Нормально вполне сделанный, имхо. Без дебилизма с форками на каждый пшик.
>> Пардон, а еще например старт процесса или треда - достаточно ресурсоемкие операции.
> Не используйте всякие виндовс :)
Так и не использую. Да, в unix-like fork() менее тяжелый вызов чем создание процесса в виндах. Но все-таки достаточно увесистый. Избавление от оного - очень даже воздается скоростью работы.
> И выучите в документации место, где написали про то как минимизировать
> необходимость сих "ресурсоемких операций"...
Да... в nginx их число очень хорошо минимизировано. Прямо на уровне парадигмы сервера :). В фастцги - примерно аналогично, такой трындец не пройдет просто на уровне парадигмы протокола.
> когда вы просто хотите на большое красное пятно Юпитера своими
> глазами полюбоваться? Бинокля хватит ;)
Если это про опач то там рассуждают так: делать хорошую оптику в бинокле - это дорого! А давайте мы лучше возьмем китайский театральный бинокль с пластиковыми линзами, но зато запустим чувака с ним на орбиту Юпитера! Энтерпрайзы же - они богатые, на ракету скинутся. Зато на изготовлении линз бинокля вон сколько сэкономим.
> Если нормально сформулировать условия задачи - можно и для апача сделать оценку.
> Причем не только "авторам"...
Ну вот на сайте нжинкса для именно этой цифры дана оценка. С удовольствием послушаю сколько у вас при этом опач жрет. Особенно если с префорком :)
И да, куча малоактивных соединений - это как раз вполне нормально для современных сайтов с AJAX во все поля и прочая.
>> Так апач и по сей день префорк сватает по дефолту
> nginx "по дефолту" вообще не умеет проксировать. Покажите мне дистрибутив, где
> он "по-дефолту" настроен для чего-то кроме простой отдачи статической странички. И что?
Простите, он поддерживает протоколы взаимодействия с бэкэндом сервера приложений. Ну и хватит с него. Пихать дрянь в процесс сервера и потом форкать в 100500 экземплярах такое красивое - прерогатива апача. Чтоб оно как раз как можно красивее дохло как только на сайт зайдет чуть побольше народа или вообще 1 пионер с бенчмаркалкой.
> prefork хоть как-то работает в любой роли. Разумное и безопасное умолчание
> для выбора mpm, хотя подходит больше для работы в роли бакенда.
А как по мне - отстойное и небезопасное. С точки зрения работоспособности и стабильности сервака в реальном мире. Не отличающемся особой дружественностью как известно.
>> висит куча страшилок
> О! Вот в этом и основная проблема фанбоев. Их источник знаний - хавту,
> бложеке и "страшилки".
Э не, не так. Только фанбои занимаются поиском жемчужин в куче гэ, на себе бетатестирую насколько вон та мегаэкспериментальная фича (не)глючит. А остальным надо чтоб работало. Без страшилок и оговорок.
> А у меня на каждом сервере "по дефолту" он будет просто запросы
> терять. Ибо worker_process - 1, а worker_connections - 512... Маловато будет.
Если к более-менее дефолтному апачу с префорком делать 512 соединений - там не то что потеря запросов будет, там будет полный ахтунг. В зависимости от крутоты конфига ахтунг может варьироваться, но на половине серваков такого хватит чтобы вообще издохнуть. У админа не умудренного опытом - спасибо если ssh хотя-бы залогинится при этом, чтобы хотя-бы увидеть WTF. Это кстати заставляет апачистов иной раз заниматься всякими смешными непотребными извращениями типа борьбы с многопоточными качалками и прочими ветряными мельницами.
Example: для многих модных ныне виртуалок/вдсок/... 512 процессов будет более чем за глаза чтобы там издохло все живое. А нжинкс там вообще никаких проблем не вызовет при таком раскладе.
>> Да, если вы не заметили, дефолты
> Дефолтов на каждого школьника не напасешся. А системные администраторы в курсе
> необходимости настройки ПО под задачи. Вот почему и не кричат "nginx - г-но".
Потому что он прилично работает с минимальными плясками с бубном. И неубиваем практически "сам по себе". По крайней мере, я видел ряд вполне успешных "ресурсных" пионерских атак на апача, вполне эффективно валившие довольно мощные серваки, при том что атакующему атака вообще не стоила можно считать что ничего. А вот чтобы кто-то так смог нжинкс уронить - не, не видел :)
