Javascript-форум (https://javascript.ru/forum/)
-   Оффтопик (https://javascript.ru/forum/offtopic/)
-   -   Apache против nginx (https://javascript.ru/forum/offtopic/60116-apache-protiv-nginx.html)

Mаxmaxmаximus 13.12.2015 00:03

Цитата:

Сообщение от cyber
Ты не пробывал на работу устроится?)

Я на себя работаю) просто бывают просадки а бывает что на турбазе шашлыки жру сутками. Нормлаьное явление когда не работаешь на дядю. Да и вообще если устраиваться на быдло работу то это считай что автоматически похерил жизнь. Ничего не создашь, ничего не изобретешь, ничего не изменишь. А Тупо будешь занмиаться своим выживанием. Это не по мне. Как говорится стей хангри, стей фуллеш.

MiksIr 13.12.2015 13:59

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

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

Так как один процесс выполняется последовательно, то и все соединения обрабатываются последовательно. И было бы совсем печально, но некоторые операции можно переложить на ядро операционной системы (как бы другой процесс). Эти операции - ожидание ответа при общении по 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 их вытеснили.

kobezzza 13.12.2015 14:04

https://h2o.examp1e.net/

MiksIr 13.12.2015 14:10

Цитата:

Сообщение от kobezzza (Сообщение 399795)

Все преимущества в скорости, даже если они не искусственные, придут и похерят рубисты встроенным руби ;))


Часовой пояс GMT +3, время: 18:42.