Vă aduc la cunoștință cercetarea privind performanța php (sau, mai degrabă, opțiunea preferată special pentru Bitrix) în diferite moduri de lansare. Scopul nu a fost acela de a obține cifre privind posibila participare, și anume să compare opțiunile diferite cu celelalte lucruri fiind egale.
GGI este cel mai vechi mod de a rula scripturi (inclusiv php). În acest caz, pentru fiecare lovitură, interpretul php rulează ca o aplicație de sine stătătoare și îi este dat un script pentru a rula. Scriptul ar trebui să returneze anteturile, apoi codul html al paginii. După aceea, interpretul își oprește activitatea.
Modulul Apache - în acest caz php este în permanență în memoria serverului web, nu este nevoie de timp pentru a porni interpretul.
FastCGI este evoluția interfeței CGI, în acest caz php este inițiat de un proces separat, dar după ce scriptul este executat, acesta nu se oprește.
Este într-adevăr atât de rapid, acest FastCGI? Să verificăm!
Apache 2.2 + MySQL 5 este instalat pe o singură mașină, precum și site-ul demo Bitrix Business. Componenta cache Bitrix a fost dezactivată, astfel încât re-crearea aleatorie a cache-ului nu afectează rezultatele.
Aici, în mod deliberat, nu mă concentrez pe hardware și configurație. Repet, sarcina nu este de a obține valori absolute, ci de a compara diferitele moduri de funcționare ale php.
O altă mașină din rețeaua locală creează o simulare a încărcării pe server. Pentru asta, am folosit JMeter.
Este scris în Java și creează o încărcătură decentă. astfel încât pentru puritatea experimentului a trebuit să o "separ" de server.
Planul de testare a constat din 6 pagini, 2 cereri paralele. Am încercat să aleg cele mai dinamice pagini încărcate, pentru a le permite să le dau numele condiționale pentru conținut. Nu asociați rata de returnare a paginilor cu aceleași module.
Numai codul dinamic al paginii a fost descărcat fără statică, așa că nginx nu a folosit-o (detalii în cursul de formare).
Deci, totul este gata, începem testarea.
Testarea fără accelerator php
CGI
Următorul grafic al rezultatelor sumare pentru toate paginile a fost obținut:
Albastru - timpul mediu de recul la fiecare lovitură în ms
Purpurie - medie statistică
Red - abatere de la mijloc
Ecranul verde - pagini de întoarcere
Ca rezultat, avem un timp mediu de 5,5 secunde pe pagină, viteza paginilor de feedback - 105 pe minut.
Rețineți că aici timpul pentru pagină este timpul în care utilizatorul așteaptă într-adevăr și nu media pentru toate cererile paralele (în al doilea caz primim 105/60 = 1,75 secunde pe pagină).
Separat pe pagini avem o astfel de diagramă (timpul de răspuns mediu):
Aici rezultatul este mai bun - 122 de pagini pe minut. În consecință, diagrama:
Un rezultat bun în comparație cu CGI tradițional: 120 pagini pe minut, ușor mai lent decât modulul.
diagramă:
Dar cum se va schimba imaginea dacă este instalat acceleratorul php?
Rezultatele testului cu EAccelerator instalat
CGI - EA
Se știe că acceleratorul nu funcționează în modul CGI. el are nevoie de acces la memoria partajată din toate procesele. Dar în phpinfo există informații despre încărcarea eacceleratorului și despre faptul că funcționează. Să verificăm.
108 pagini pe minut. Acesta este practic același rezultat ca și cum a fost. diagramă:
309 de pagini pe minut, timpul mediu de răspuns este de 1 secundă. Aș spune că este deja ceva. Ei bine, respectiv, pe paginile:
294 pagini pe minut, adică aproximativ 5% mai lent decât modulul. Dar totuși nu este în nici o comparație cu modul CGI tradițional și proastă.
În medie, paginile prezintă, de asemenea, o ușoară întârziere în spatele modulului.
Există alte probleme?
Vizitatorii folosesc frecvent CGI pentru că în acest caz este mult mai convenabil să gestionați resursele de citire [read: cut]. Și ca rezultat avem "greșeli incomprehensibile".
Vreau să menționez un alt punct important: astăzi php este un fișier pentru modurile CGI și FastCGI, în phpinfo vedem:
Server API: CGI / FastCGI
Deci, este ușor posibil la nivel de utilizator să afle cum funcționează php-ul. Având în vedere documentația slabă cu privire la înființarea FastCGI, poate fi foarte bine că veți fi induși în eroare.
Concluzii sau "Cum să alegi un hostess?"
Dacă sunteți un utilizator simplu, probabil ați derulat întreaga sarcină tehnică pentru a găsi imediat răspunsul la întrebare.
- Alegeți modul CGI dacă site-ul dvs. este dedicat filozofiei orientale și timpul de încărcare a paginilor vizitatorilor pe site nu este excite.
- FastCGI oferă rezultate bune de performanță, dar are probleme în modul CGI, iar acestea sunt erori permanente ale serverului de "500".
- În alte cazuri, vă recomandăm să utilizați php ca modul Apache. Mai ales dacă este un server dedicat sau VPS.
- Asigurați-vă că acordați atenție acceleratorului php. Din păcate, mulți vizitatori nu acordă atenția cuvenită acestei probleme.
- Iată un alt aspect important: nu alegeți gazda unui vecin pe scară, uneori incapacitatea elementară de a configura sistemul aduce mai multe probleme decât orice altceva. Alegeți profesioniști.
- Vă recomandăm să o testați cu scriptul nostru înainte de achiziționarea pe termen lung a gazdei. Actualizăm periodic scenariul ținând cont de noile probleme.
Consultați-vă și trageți concluzii. Din păcate, utilizatorul începe să înțeleagă importanța găzduirii "corecte" numai după ce a întâmpinat o serie de probleme.
Trimiteți-le prietenilor: