Green Myshko apache performanță de optimizare

Potrivit Netcraft, Apache - cel mai popular server de web de pe Internet, acesta servește mai multe servere și site-uri. De multe ori este necesar pentru a crește performanța de server de web. Probabil cel mai bun mod de a face acest lucru - la aspectul frontend + backend, dar poate necesita modificări destul de importante la cererea (de exemplu, probabil cad tot felul de indicatori de progres încărca în general fișiere).

Un alt mod - crește doar performanța serverului - pentru a oferi un procesor mai rapid și mai multă memorie.

Cu toate acestea, primul și cel de-al doilea necesită o mulțime de timp și resurse, astfel încât prima dată, puteți încerca să accelereze apache prin optimizarea configurației sale. Există optimizări care pot fi aplicate numai atunci când recompilare apache, în timp ce altele pot fi folosite fără a fi nevoie să recompilați server.

Încărcați numai modulele necesare

Apache - program de modul, cele mai multe funcții sunt implementate în module. Astfel, aceste module pot fi compilate în ambele și colectate ca DSO - biblioteci dinamice. Cele mai multe distribuții moderne vin cu un set de DSO apache, deci nu au nevoie de modulele pot fi dezactivate cu ușurință, fără recompilare.

Selectați dreapta MPM

În apache fiecare cerere este procesată într-un proces sau fir. Când compilarea apache vă permite să selectați unul dintr-un număr de MPM (modul de procesare a Multi), care sunt responsabile pentru porturi de ascultare, primirea cererilor și distribuirea acestor procese cereri pentru copii sau fire, în care au fost procesate aceste cereri.

MPM alegere depinde de mai mulți factori, cum ar fi disponibilitatea de sprijin firului în sistemul de operare, cantitatea de memorie liberă, precum și cerințele de stabilitate și siguranță.

În cazul în care securitatea este importantă, trebuie să selectați peruser MPM, sacrifica performanța.

În cazul în care performanța este importantă, alegerea este limitată la două MPM: prefork și muncitor.

Muncitor - MPM-line, și anume, în aceasta fiecare cerere este deservit de un fir separat de unul dintre procesele copil. Fluxurilor - mai multe obiecte luminoase pentru sistemul de operare decât procesele pe care le utilizează memorie mai eficient, iar comutarea de context pentru a le mai repede. Cu toate acestea, datorită faptului că fiecare fir are acces la întreaga memorie de proces, MPM lucrător mai predispuse la eșec: defectarea unui flux poate provoca o scădere a întregului proces, care a fost fluxul (de aici MPM lucrător se execută mai multe procese copil cu mai multe fire în fiecare ).

Perfork - MPM utilizează mai multe procese copil, fiecare copil se ocupă de o conexiune de proces. Datorită faptului că procesul - mai grele structura, se folosește un ușor mai multe resurse, dar este mai puțin probabil să accident - procesarea fiecărei cereri este independentă de alte procese.

Din păcate, pentru a schimba MPM apache necesita recompilarea. Apoi arată distribuțiile bazate pe sursa de avantaje: puteți recompilați cu ușurință și apache toate pachetele dependente, fără a transforma sistemul într-un depozit de deșeuri. distribuții binare din această situație în mod diferit. Cum ar fi RHEL în rpm apache este doar două versiuni de apache - cu lucrătorul și prefork MPM (prefork este implicit). Cu toate acestea, MPM lucrător nu are suport pentru PHP. Deci, dacă doriți să PHP și MPM lucrător trebuie să-l compilați singur sau găsi o arhive terță parte.

interogări DNS

AllowOverride

În cazul în care directiva AllowOverride nu este setat la „Niciuna“, apache va încerca să deschidă fișiere .htaccess în fiecare director pe care o frecventeaza si toate directoarele de mai sus ea. De exemplu:

Dacă vi se solicită /index.html, apache va încerca să deschidă (și interpreta) fișiere /.htaccess, /var/.htaccess, /var/www/.htaccess și /var/www/html/.htaccess. Acest lucru mărește timpul de procesare a cererii. Deci, dacă aveți nevoie de un .htaccess doar un singur director, lăsați-l doar pentru ea:

FollowSymLinks și SymLinksIfOwnerMatch

Mai mult decât atât, apelurile de sistem suplimentare necesare atunci când FollowSymLinks nu este instalat. astfel situația optimă pentru performanță - când opțiunea FollowSymLinks este activată.

Conținut Negotiatio

Evitați negotiaion de conținut.

MaxClients

Directiva MaxClients stabilește numărul maxim de cereri concurente pe care serverul va sprijini. Apache nu va crea mai multe procese / fire decât MaxClients. Înțeles MaxClient Dolno să nu fie prea mici (în caz contrar mulți clienți rămân fără servicii hoteliere), dar nu ar trebui să setați prea mult - este mai bine să nu pentru a servi unor clienți decât să epuizeze toate resursele pentru a intra în swap și să moară sub sarcină. O valoare bună poate fi MaxClients = cantitatea de memorie alocată unei / dimensiunea maximă a unui proces de copil sau fir de server web. Pentru fișierele statice, apache utilizează aproximativ 2-3 MB în proces, pentru difuzoare (PHP, CGI) - depinde de script-ul, dar este, de obicei, aproximativ 16-32 MB.

Puteți estima dimensiunea aproximativă uita la coloana RSS în producția de `ps -ylC httpd --sort: rss`

Dacă serverul este de servire deja MaxClients cereri, noi cereri vor cădea în loc, dimensiunea care este stabilită prin Directiva ListenBacklog.

MinSpareServers, MaxSpareServers și StartServers

pentru că crearea unui fir, în special un proces - o operațiune costisitoare, apache le creează în avans. Directiva MaxSpareServers MinSpareServers și setați cât de multe procese / fire trebuie să aștepte în disponibilitatea de a accepta cererea (maxim și minim). Dacă valoarea este MinSpareServers prea mic și de a lua brusc o mulțime de cereri, apache va trebui să creeze o mulțime de noi procese / fire, ceea ce va crea o povară suplimentară în această situație stresantă. Pe de altă parte, dacă MaxSpareServers prea mare, apache va încărca mult aceste procese sistem, chiar dacă numărul de clienți este minim.

Încercați să stabilească astfel de MinSpareServers și MaxSpareServers, apache nu pentru a crea mai mult de 4 procese / fire pe secundă. Dacă el creează mai mult de 4 din ErrorLog va pune un mesaj pe el. Acesta este - un semnal că MinSpareServers prea puțin.

MaxRequestsPerChild

Directiva MaxRequestsPerChild stabilește cât de multe interogări pot ocupa un proces de copil / fir înainte de a fi finalizat. Valoarea implicită pentru această directivă este setată la 0, ceea ce înseamnă că, odată creat, procesul / firul este complet niciodată (bine, cu excepția serverului sau a opri colapsul procesului / fir). Vă recomandăm să instalați MaxRequestsPerChild egal cu unele număr destul de mare (câteva mii). Acest lucru nu va crea sarcini inutile, sunt în legătură cu faptul că apache va trebui să creeze noi procese copil, în timp ce, în același timp, va ajuta să scape de probleme cu scurgeri de memorie în procesul de copil (care este posibil, de exemplu, dacă utilizați php versiune instabilă).

Keepalive și KeepAliveTimeout

Keepalive permite mai multor cereri într-un singur TCP-conexiune. Acest lucru este util mai ales pentru HTML-pagini cu o mulțime de imagini. Dacă keepalive set este oprit, apoi pagina în sine și pentru fiecare imagine să fie creată o conexiune separată (care va trebui să se ocupe de master-proces), care este rău atât pentru server și client. Deci, este recomandat să setați KeepAlive la On pentru astfel de cazuri. Pentru alte aplicații (de exemplu, pentru download-server) Keepalive poate fi inutilă sau chiar dăunătoare, deoarece KeepAlive atunci când serverul închide conexiunea imediat, dar de așteptare pentru KeepAliveTimeout secunde o nouă cerere. Pentru a procesa nu prea mult timp atârnat în așteptare inutil KeepAliveTimeout set suficient de mici, aproximativ 5-10 secunde, este de obicei suficient.

HTTP-compresie a fost definit în standardul HTTP / 1.1, iar acum toate cele mai recente programe de client și aproape toate de sprijinul său servere. Serverul poate da un răspuns în gzip sau dezumfle, iar programul client, fără ca utilizatorul decomprimă datele. Acest lucru reduce cantitatea de trafic transmis (la 75%), dar, desigur, crește utilizarea procesorului.
Cu toate acestea, în cazul în care serverul este vizitat de mulți clienți cu conexiune lentă, de compresie poate reduce sarcina de pe server, deoarece serverul va fi capabil să transfere rapid răspunsul comprimat și a elibera resursele ocupate printr-un proces de copil. Mai ales puternic acest efect poate fi vizibil dacă aveți un procesor rapid, dar puțină memorie.

caching client-side

Nu uitați să setați Expiră antet pentru fișierele statice (a se vedea. modulul Mod_expires). Dacă fișierul nu se schimba, atunci ar trebui să încercați întotdeauna să cache pe client. Apoi, clientul va încărca paginile mai repede, iar serverul este liber de interogări inutile.