Green Myshko въвеждане Nginx, част 1

Какво е Nginx толкова добър и защо е толкова любители на администраторите високо натоварване? Защо просто не се използват Apache?

Защо Apache - лошо?

Първо трябва да се обясни как се работи с всички мрежови сървъри. Тези, които са запознати с мрежата програмиране, знаем, че в действителност има три модела на сървъра:

Последователно. Сървърът открива гнездо слушане, и изчаква се появява връзката (докато го чака, е в заключено положение). Когато става въпрос за връзката, сървърът обработва в същия контекст, се затваря връзката и след това чака за връзка. Очевидно е, че това не е най-добрият начин, особено при работа с клиенти, се провежда в продължение на дълъг период от време и много връзки. В допълнение, в съответствие модел все още има много недостатъци (например, невъзможност да се използват множество процесори), както и в реално изражение това почти никога не се използва.
Многопроцесен (многонишкова). Сървърът открива гнездо слушане. Когато става въпрос за връзката, той го взема, а след това създава (или избира от група от предварително създадени) нов процес или нишка, която може да бъде произволно дълго време да работи със съединението, а след завършване на работата или да се върне в басейна. Основната нишка, междувременно, е готов да приеме нова връзка. Това е най-популярният модел, защото тя се реализира сравнително лесно, като ви позволява да извършвате сложни и дълги изчисления за всеки клиент и да използва всички налични процесори. Един пример за използването му - Apache Web-сървър. Този подход обаче има и своите недостатъци: голям брой едновременни връзки създал много потоци (или, по-лошо, процеси) и операционната система прекарва много ресурси на контекстни ключове. Особено лошо, когато клиентите са много трудно възприемане на съдържанието. Получава стотици нишки или процеси, които участват само изпращане на данни на клиенти бавни, което създава допълнителна тежест за планировчика на операционната система, увеличава броя на прекъсванията и консумира много памет.
Non-блокиращи контакти / държавна машина. Сървърът работи в един конец, но използва не-блокиращи контакти и механизъм избирателната. Т.е. сървър на всеки безкраен цикъл итерация избира всичко от контакта, че е готов за получаване / изпращане на данни чрез отметка () повикване. След като е избран от контакта, сървърът изпраща данни към него или да ги четат, но не изчака потвърждение и се движи към първоначалното състояние и чака случай към друг контакт или преработва следващия, в който случай настъпили по време на предходно лечение. Този модел е много ефективно използване на процесора и паметта, но това е доста сложно за изпълнение. Освен това, в този модел за обработка на събитието за контакт трябва да се извършва много бързо - в противен случай на опашката ще се натрупват много събития, както и в края на краищата тя ще прелее. Тя е за този модел работи Nginx. Освен това, той позволява да тече няколко работни процеси (така наречените работници), т.е. Тя може да се използва повече от един процесор.

Така че, представете си следната ситуация: в канала на HTTP сървър 1 Gbit / сек до 200 клиенти, присъединени към канала на 256 Kbit / и:

Какво се случва в случай на Apache? Той създава 200 нишки / процеси, които са относително бързо генериране на съдържание (тя може да бъде и двете динамични страници и статични файлове от диска се чете), но бавно даде на клиентите си. Операционната система трябва да се справи с много нишки и аз / заключване O.
Nginx в тази ситуация прекарва на всяка връзка порядък по-малко ресурси на операционната система и паметта. Въпреки това, все се разкрива ограничен модел мрежа Nginx: тя не може да генерира динамично съдържание в себе си, защото това ще доведе до блокиране вътре Nginx. Разбира се, има решение: Nginx е в състояние да прокси тези искания (на съдържание поколение) до всеки друг уеб сървър (например, една и съща Apache), или към сървъра на FastCGI.

Помислете механизъм Nginx сухожилия служат като "основен" Apache сървъра и като сървър за генериране на динамично съдържание:

Nginx приеме връзката от страна на клиента и я прочете цялата заявка. Тук трябва да се отбележи, че докато Nginx не четат цялата заявка, тя не го даде на "лечение". Поради това, обикновено е "счупени" почти всички индикатори на хода на изтеглянето на файлове - обаче, е възможно да го поправим с помощта на модул upload_progress на трета страна (това ще изисква модифициране приложения).
След като Nginx прочетете целия отговор, той се отваря връзка с Apache. Последно свършена работа (генерира динамично съдържание), и след това дава своя отговор на Nginx можех, че тя буфери в паметта или временен файл. В същото време, Apache освобождава ресурсите.
Следваща Nginx бавно дава съдържание на клиента, докато разходите по нареждане на по-малко средства, отколкото Apache.

Тази схема се нарича интерфейса + гръб (интерфейса + гръб) и се използва много често.

защото Nginx е просто започва да набира популярност, има някои проблеми с бинарни пакети, така че да бъдат подготвени за факта, че тя ще трябва сами да компилирате. Това обикновено не е проблем, ние просто трябва да прочетете внимателно изхода на ./configure --help и изберете опции изисква време на компилация, като тези:

В този конфигурационен файл

Nginx конфигурационен файл е много лесен за използване и интуитивен. той обикновено се нарича nginx.conf и се поставя на $ префикс / конф /, ако местоположението не е отменено от компилатора. Харесва ми да го поставите в / и т.н. / Nginx /, а също и да направи разработчиците на всички пакети, споменати по-горе.
Структурата на конфигурационния файл е както следва:

Имайте предвид, че всяка директива трябва да завършва с точка и запетая.
Обратната прокси и FastCGI

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

Това е много проста! Подобно на това:

В този пример, всички искания, които влизат на мястото / ще се използва прокси сървър, към сървъра 1.2.3.4 порт 8080. Тя може да бъде като Apache, или всеки друг HTTP сървър.

Nginx конфигурация в този случай е, както следва:

Друг вариант задния - е да се използва FastCGI. В този случай конфигурацията Nginx ще изглежда така:

# Благодарение на факта, че lokeysheny с регулярни изрази имат по-голяма "приоритет" тук няма да получи искания изцяло PHP.

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

В конфигурационния файл изглежда така:

Ако всичко смущенията не се поставя във всеки конкретен директория, използвайте регулярен израз:

За да се продължи

Тук можете да намерите информация за dopolnitelnouyu Nginx: