Apache и Nginx са двата най-разпространени уеб сървъри с отворен код и заедно обслужват над 50% от интернет трафика по света. Те предоставят идеални решения за уеб сървъри, като могат да работят заедно с други приложения, за да формират web stack.

Въпреки че на практика Apache и Nginx извършват идентична работа, трябва да уточним, че имат сериозни разлики, защото всеки един от тях има своята специфика, качества, предимства и недостатъци.

В следващите няколко статии ще ви запознаем с приликите и разликите им. Нека първо да ги разгледаме поотделно.

• Apache

Apache HTTP Server е най-известният software по света и затова е познат просто като Apache. Той е създаден от Robert McCool през 1995 г. и е развиван от Apache Software Foundation от 1999 г. досега. Заради своята популярност той има изключително богата документация и съвместимост с други софтуери. Той се радва на изключително внимание от страна на администраторите заради  гъвкавостта му и сериозната поддръжка.

• Nginx

През 2002г. Igor Sysoev започва работа по Nginx в отговор на C10K проблема - истинско предизвикателство за уеб сървърите, които е трябвало да обработят стотици заявки. Популярността на Nginx нараства през годините, защото заема изключително малко системни ресурси и възможността да бъде поставен на сървъри с остарял хардуер. Nginx превъзхожда в обработката на статичното съдържание, а динамичното бива поднесено на други софтуери, които се справят по-добре с тях. Много администратори предпочитат него, защото има ниски системни изисквания и може да се справи с големи натоварвания.

Connection Handling архитектура

Една от най-големите разлики между Apache и Nginx е в процеса на обработката на заявките към сървъра. Нека да разгледаме как всеки софтуер се справя с тях.

• Apache

Apache дава няколко възможности за обработка на заявките от страна на клиента, изразени в различни модули (MPMs) и администраторите могат да сменят.

Ето и самите методи:

• mpm_prefork - този метод отваря процес с единична нишка, която да обработи получената заявка. Всеки дъщерен процес може да обработва по една заявка. Докато номера на заявките е по-малък от възможните процеси, които могат да бъдат стартирани, този модул се справя изключително добре и бързодействието е значително. В случай че има повече заявки, се наблюдава значително понижаване на качеството на услугата.

Всеки процес заема известно количество RAM памет и поради тази причина MPM не е толкова гъвкав. Може да използвате този вариант в комбинация с други приложения, които не изискват допълнителни нишки.

 

• mpm_worker - този модул отваря процеси, които могат да обработват множество нишки. Всяка една от тези нишки може да обработва по една заявка. Тези нишки са по ефикасни от процесите, а това означава, че MPM е много по-гъвкав от mpm_prefork. Фактът, че има повече нишки отколкото процеси означава, че новите заявки могат да бъдат обработвани моментално и няма да изчакват процес да бъде завършен и освободен.
• mpm_event - модулът е подобен на предишния, но функцията keep-alive може да бъде управлявана. При worker MPM заявката запазва нишка без значение дали тя е активна, докато конекцията е kept alive. При event MPM отново имаме заделена нишка, но MPM-а предава активната част на заявката към друга нишка. Това означава, че модулът няма да бъде излишно натоварен с keep-alive заявки и те ще бъдат обработени по-бързо. Важно е да отбележим, че това може да бъде използвано във версия 2.4 на Apache.

Иначе казано Apache предоставя на своите потребители нужната гъвкавост и съответната оптимизация според изискванията им.

 

• Nginx

Nginx е представен като решение на проблемите, открити в годините от създаването на Apache. Това кара и разработчиците му да използват нови методи за обработка на заявките, а именно asynchronous, non-blocking, event-driven connection handling algorithm.

Nginx стартира worker процес, като всеки може да обработва хиляди заявки. Тези worker процеси успяват да обработят голямо количество заявки, защото ги имплементират в loop механизъм, който постоянно проверява за processes events.

Всяка от конекциите, която се обработва от worker процес бива поставена в event loop заедно с другите конекции, където се обработват асинхронно, което предотвратява блокирането им. След като заявката бъде обработена, тя бива премахната от loop.

Този вид обработка на заявки позволява на Nginx да бъде поставен на сървъри с малки хардуерни параметри. Тъй като не се отварят множество процеси, покачването на CPU и RAM не е значително даже и при високи нива на натоварвания.

В продължението на тази статия, ще ви запознаем със сравнение между статично и динамично съдържание при двата уеб сървъра, дистрибутирана и централизирана конфигурация и файлова срещу URI-базирана интерпретация.