Показать сообщение отдельно
  #12 (permalink)  
Старый 13.12.2015, 13:59
Аспирант
Отправить личное сообщение для MiksIr Посмотреть профиль Найти все сообщения от MiksIr
 
Регистрация: 29.05.2013
Сообщений: 71

Есть два популярных способа обработки соединений. Это либо все соединения в одном процессе ("процесс" тут и далее == процесс операционной системы). Либо одно соединение = один процесс.

(треды не беру, о них нужно отдельно)

Так как один процесс выполняется последовательно, то и все соединения обрабатываются последовательно. И было бы совсем печально, но некоторые операции можно переложить на ядро операционной системы (как бы другой процесс). Эти операции - ожидание ответа при общении по tcp/ip и некоторые операции с жестким диском. По этому принципу работает nginx. По-этому, по сути, он работает на отдачу статики и проксирование (http, fastcgi и т.п.). Поскольку он работает типа такого переключателя межу клиентом и сервером/диском - один процесс может обрабатывать десятки тысяч соединений.

Апач стандартно работает по другой схеме - процесс на соединение. Это позволяет ему в этом процессе делать все, что угодно. Например, запускать PHP через mod_php. Но в итоге одновременно соединений он может отработать не больше, чем вместится процессов в конкретный сервер. А это, обычно, сотни. И еще нужно понимать, что если интернет у клиента медленный - процесс будет жить пока не протолкнет ему всю информацию.

Т.е. вроде преимущества nginx очевидны, но нужно понимать одну штуку - nginx не допускает в своем процессе сложной математики (расчетов). Это очевидно, ибо пока процесс занят какими-то расчетами - он не может обрабатывать изменения в других соединениях. По-этому, php в nginx не приделаешь. По-этому, тяжелые расчеты выносят в отдельные процессы, которые работают по схеме - один процесс-одно соединение (как апач), а nginx c ними коммуницирует.

В ранние времена часто использовалась связка nginx+apache(mod_php). Т.е. PHP запросы передавались в апач. Потом PHP сам стал неплохо работать как сервер по протоколу FastCGI, и апач стал не нужен. Это я к чему. Если у вас все запросы - в динамику (в PHP, например), да еще все быстрые соединения, то никакой разницы, кто будет принимать их - нет, хоть апач, хоть nginx.

А вот как появляются статические файлы, медленные клиенты - тут ставят легкий сервер вперед. Ибо апач будет рождать новый процесс даже что бы просто файл отдать, а это затратно. Или перед апачем, или вообще апач выкидывают, если его можно заменить.

К слову, в апаче давно уже появились разные mpm, т.е. способы обработки соединений. Но так и остались экзотикой, легкие сервера типа nginx, lighttpd их вытеснили.
Ответить с цитированием