Cum Nginx http-server

Cum HTTP-server de Nginx

Pentru o lungă perioadă de timp, Apache este cel mai popular HTTP-server open source. Dar poate fi prea greoaie pentru unii padach. Și aici, pe o scenă sunt jucători noi - ușoare, asincrone HTTP-servere, dintre care unul este Nginx.

Acum, când am avut două opțiuni, a fost cel mai dificil lucru - pentru a alege cele mai potrivite pentru cazul meu. Aceasta este o alegere dificilă, deoarece ambele au aproape aceleași posibilități (deși nginx poate fi de asemenea folosit ca un server de mail proxy, nu am luat în considerare în comparație). Ambele sunt utilizate în site-uri foarte frecventate, de exemplu, YouTube utilizând Lighttpd, AND Rambler - Nginx. Ambele au o documentație destul de bună, inclusiv Nginx are documentația în limba rusă. Ca urmare, pentru mine, m-am oprit la Nginx din următoarele motive:

Înainte de a porni să ia în considerare în mod direct serverul Nginx, ia în considerare diferența dintre asincron (eveniment) din abordarea procesare paralelă a compușilor în procese sau fire separate.

În cel mai simplu caz, procesarea paralelă a compușilor procesului de bază a fost de așteptare pentru conexiunile de intrare, și apoi trimite lucrarea de prelucrare a unei noi conexiuni la procesul de copil, sau un flux separat. În această abordare are următoarele avantaje:

n Acesta este un model simplu pentru software-ul de server și de plug-in-uri.

Fiecare compus n este tratat în mod independent, și astfel o posibilă procesarea datelor lungi efectuate într-un singur proces (fir) nu afectează celelalte.

n Această abordare nu scară. De exemplu, 1000, conexiuni deschise simultane poate fi destul de normal în număr, dar în 1000 procese concurente sau fire poate fi o problemă.

prelucrarea asincronă în cazul unui singur proces cu un singur fir, un apel special sistem de expedieri prize deschise și descriptori de fișiere. Acest apel sistem returnează numai mufele și mânerele, gata pentru a deschide o conexiune, citi sau scrie. Deoarece cele mai multe ori, de obicei, petrecut de așteptare pentru intrare-ieșire și viteza procesorului în memoria de viteză de multe ori mai mare de intrare-ieșire, puteți avea timp pentru a efectua prelucrarea necesară a datelor, în timp ce sistemul este în așteptare pentru ei un nou lot. Avantajele acestei abordări:

n Pentru multe aplicații, doar un singur proces cu un singur fir se poate ocupa mai multe conexiuni decât în ​​cazul procesării paralele.

n Deoarece un singur proces cu un singur fir poate suporta mai multe conexiuni pentru a gestiona mai mulți compuși care utilizează mai puține resurse.

n Programarea aplicațiilor asincrone poate fi mai dificilă decât cu aplicații de procesare paralelă.

n În cazul utilizării doar un singur proces cu un singur fir, poate fi dificil să scară, deși mai bine decât procesare paralelă.

n În cel mai simplu caz abordarea asincron nu poate fi utilizată în cazul în care este necesar o prelucrare lungă.

După cum puteți vedea, ambele abordări au avantajele și dezavantajele lor. Pentru a combina avantajele și dezavantajele minimiza ale ambelor abordări sunt în prezent pentru aplicațiile de rețea asincrone cele mai populare abordare hibridă, în care mai multe aplicații asincrone funcționează în paralel în procese sau fire separate. Acum, să vedem cum funcționează în Nginx.

Construirea și instalarea

In timp ce Nginx deja disponibile în pachete pentru cele mai recente versiuni de Ubuntu Linux, am decis să-l construiască de la sursă, pentru că am vrut să folosească o versiune mai recentă și mod_wsgi stabilă modul de mai mult pentru a sprijini Python WSGI-protocol. Dacă nu aveți nevoie pentru a colecta cu mod_wsgi Nginx, puteți sări peste toate locurile unde este menționat.

Deci, avem nevoie pentru a construi codul sursă Nginx, s-a putut codul sursă de bibliotecă Perl compatibile Expresii regulate (PCRE), și codul sursă al modulului mod_wsgi. Aici, vom folosi mai târziu, în acest moment, versiunea mod_wsgi și biblioteca PCRE. Dacă utilizați versiuni mai vechi ale PCRE versiune nu ar trebui să fie mai mică de 4.4:

$ Tar -xzf Nginx-0.6.32.tar.gz

$ Tar -xjf pcre-7.8.tar.bz2

$ Tar -xzf mod_wsgi.tar.gz

$ Mv mod_wsgi-8994b058d2db mod_wsgi

if (r-> metoda == NGX_HTTP_GET || r-> Metoda == NGX_HTTP_HEAD)

în cazul în care (rc! = NGX_OK rc! = NGX_AGAIN)

Și apoi vom face:

$ Patch -d mod_wsgi -p0

Pentru a asambla cu Nginx SSL, de asemenea, necesitatea de a instala biblioteca OpenSSL pentru utilizare ngx_http_gzip_module modul zlib bibliotecă. Pentru a asambla mod_wsgi trebuie să instalați pachetul python-dev:

$ Sudo apt-get install libssl-dev

$ Sudo apt-get install zlib1g-dev

$ Sudo apt-get install python-dev

$ Chmod a + x nginx.sh

Luați în considerare ordinea opțiunilor:

n Opțiunea de utilizare descrie procesele de lucru vor fi efectuate în numele unui utilizator și de grup.

n worker_processes opțiune specifică numărul de procese de lucru. Numărul de procese de lucru - un parametru care afectează performanța și în principal depinde de sarcina preconizată pe server și funcționalitatea necesară a site-ului. În cel mai simplu caz, acesta poate fi doar un singur proces de lucru, dar dacă se utilizează compresia de date, sau SSL, numărul acestora poate fi egal cu numărul de procesoare sau aproximativ de două ori numărul. În acest caz, am ales procesul 4 de lucru, după cum un exemplu de un site web static și folosește compresie, și SSL și rulează pe o mașină dual-procesor. În cazul în care dacă utilizați nu este destul de module sincrone Nginx tipice, cum ar fi mod_wsgi, trebuie să selectați numărul de procese de lucrători, în funcție de numărul estimat de cereri concurente și viteza de procesare a acestora.

n Opțiuni error_log și pid, descrie calea către jurnalul de erori cu nivelul de logare și calea către fișierul în care pentru a stoca identificatorul procesului principal server.

n secțiunea evenimente descrie opțiunile legate de manipulare eveniment. worker_connections Opțiunea descrie limitarea numărului de conexiuni concurente de flux de lucru. Astfel, în cazul statică numărul maxim site-ul de conexiuni simultane la serverul poate fi calculat cu formula: worker_processes * worker_connections. De asemenea, în această secțiune puteți selecta metoda de manipulare eveniment, de exemplu, utilizarea epoll și alte setări legate de manipulare eveniment.

secțiunea n http descrie configurația HTTP-server și toate site-urile. Opțiunile includ și descrie default_type de tipurile MIME directorul și tipul implicit, respectiv. Opțiunea charset specifică codificarea care va fi adăugat la antetul de răspuns Content-Type. În cazul în care nu este specificat, browsere va utiliza propria codificare implicit ca codificarea de conținut. Opțiunea Server_tokens controlează ieșirea numărul versiunii serverului în răspunsurile. Opțiunea include utilizarea apelului sistem sendfile, optimizarea fișierelor pachet. Setați opțiuni, începând cu gzip, descrie opțiunile de compresie de răspunsuri. Setați opțiuni, începând de la SSL, descrie setarea SSL sesiuni. Această opțiune conectează include un alt fișier de configurare, în acest caz, direct la configurația site-ului.

Configurația site-ului poate fi după cum urmează:

server_name example.ru * .example.ru;

error_log info /var/log/nginx/example.ru/error.log;

în cazul în care ($ gazdă! = "example.ru")

error_log info /var/log/nginx/example.ru/error.log;

auth_basic "Exemplu loc admin";

protejat HTTPS-de obicei HTTP-versiune și versiunea printr-o parolă - în acest caz, /etc/nginx/example.ru.conf fișier descrie două versiuni ale site-ului. Secțiunile descriu serverul de configurare servere virtuale.

Luați în considerare mai multe opțiuni:

n Opțiunea nume_server specifică numele și alias-ul site-ului.

n Opțiuni error_log și access_log determină calea către jurnalul de erori cu nivelul de exploatare forestieră și log interogări, respectiv.

n Secțiunea locație combină parametrii de configurare în funcție de URI de solicitare.

n Opțiuni rădăcină și indexul descrie directorul rădăcină al site-ului și numele fișierului index implicit.

n și rescrie cazul în care opțiunile sunt folosite pentru a modifica URI de solicitare. În acest exemplu, toate cererile pentru alte domenii sunt redirecționate către example.ru.

n Opțiuni începând cu ssl_, descrie calea către SSL-certificatul și cheia privată, respectiv.

HTTP-server este de multe ori doar un intermediar (proxy), cu care se confruntă celălalt HTTP-server. De exemplu, este nevoie de o astfel de configurație în cazul în care unul dintre site-urile se face cu utilizarea tehnologiei, care are deja propria HTTP-server sau agent este utilizat ca un balansier de încărcare pentru mai multe servere din spatele ei. În Nginx, această funcționalitate este susținută de modulul ngx_http_proxy_module.

proxy_set_header gazdă $ gazdă;

proxy_set_header X-Real-IP $ REMOTE_ADDR;

proxy_set_header X-Transmis-Pentru $ proxy_add_x_forwarded_for;

Aceste opțiuni set antete suplimentare, care vor fi transferate pe un server secundar, și conectați fișierul de configurare site-ului. Configurația site-ului poate fi după cum urmează:

error_log info /var/log/nginx/zope3.example.ru/error.log;

error_page 502503504 /maintenance.html;

fastcgi_param SCRIPT_FILENAME /home/www/php.example.ru/data$fastcgi_script_name;

Pe lângă opțiunile deja bine cunoscute, există o secțiune care specifică acțiunile pentru toate căile care se termină în .php:

n opțiunea fastcgi_index specifică numele fișierului index FastCGI.

n Opțiunea include fișierul conectăm cu parametrii care vor fi transmise la FastCGI-interogări. Din păcate, nu ne putem conecta odată ce acești parametri la un nivel ridicat, deoarece Opțiunea următoare fastcgi_param, care, la rândul său, un alt parametru specifică suplimentar anulează toți parametrii care determină un nivel mai înalt.

Personalizabil cu Python WSGI

wsgi_var REQUEST_METHOD $ request_method;

QUERY_STRING wsgi_var $ QUERY_STRING;

CONTENT_TYPE wsgi_var $ CONTENT_TYPE;

CONTENT_LENGTH wsgi_var $ CONTENT_LENGTH;

SERVER_NAME wsgi_var $ server_name;

SERVER_PORT wsgi_var $ SERVER_PORT;

SERVER_PROTOCOL wsgi_var $ SERVER_PROTOCOL;

wsgi_var REQUEST_URI $ REQUEST_URI;

wsgi_var DOCUMENT_URI $ document_uri;

DOCUMENT_ROOT wsgi_var $ DOCUMENT_ROOT;

SERVER_SOFTWARE wsgi_var $ nginx_version;

wsgi_var REMOTE_ADDR $ REMOTE_ADDR;

REMOTE_PORT wsgi_var $ remote_port;

SERVER_ADDR wsgi_var $ server_addr;

REMOTE_USER wsgi_var $ REMOTE_USER;

După aceea va trebui să adăugați la /etc/nginx/nginx.conf în opțiunile http secțiunea:

Acum face script-ul WSGI-Trac pentru a conecta și setați-o ca /home/www/wsgi.example.ru/wsgi.py, fără a uita de a face executabil:

Și ultimul punct - configurația site-ului:

error_log info /var/log/nginx/wsgi.example.ru/error.log;

Aici opțiunea wsgi_pass specifică numele de script-ul care urmează să fie executat într-un flux de lucru. Prin urmare, din moment ce scripturile rula sincronă în fluxul de lucru pentru a optimiza performanța site-ului cu WSGI, va trebui să crească valoarea opțiunilor în worker_processes nginx.conf.

cerere def (environ, start_response):

întoarce [ „lume Bună ziua!“]

Astfel, protocolul permite, de exemplu, începe să depana aplicația Web folosind wsgiref pachet standard (apărut în Python 2.5), apoi mergeți la mod_wsgi (cu n GINX sau Apache) sau serverul HTTP într-un cadru asincron răsucite.