Entitate „cadru” pentru PHP dintr-o clasă. Rușii din echipa de bază PHP: „Limba crește ca coralul” Anemic group php

Dacă ați dezvoltat PHP în ultimii ani, probabil că sunteți conștient de problemele limbajului. Veți auzi adesea că este un limbaj fragmentat, un instrument de hacking, că nu are specificații reale etc. Realitatea este că PHP a crescut foarte mult în ultima vreme. PHP 5.4 l-a adus mai aproape de un model de obiect complet și a introdus o mulțime de funcționalități noi.

Și toate acestea sunt bune, desigur, dar cum rămâne cu cadrele? Există un număr mare de ele în PHP. Odată ce începi să cauți, îți vei da seama că nu vei avea suficient timp să le studiezi pe toate, pentru că noi cadre apar constant și se inventează ceva diferit în fiecare. Deci, cum transformi acest lucru în ceva care nu înstrăinează dezvoltatorii și care permite portarea funcționalității cu ușurință de la un cadru la altul?

Ce este PHP-FIG

PHP-FIG (PHP Framework Interop Group) este un grup organizat de dezvoltatori al cărui scop este să găsească modalități prin care mai multe cadre să funcționeze împreună.

Imaginează-ți: în prezent susții un proiect Zend Framework care are nevoie de un modul de coș de magazin. Ai scris deja un astfel de modul pentru un proiect anterior, care era pe Symphony. N-ar trebui să o facem din nou? Din fericire, atât ZendF, cât și Symphony fac parte din PHP-FIG, așa că puteți importa un modul dintr-un cadru în altul. Nu e grozav?

Să aflăm ce cadre sunt incluse în PHP-FIG

Membri PHP-FIG

Orice dezvoltator își poate adăuga cadrul pe lista participanților PHP-FIG. Cu toate acestea, va trebui să plătiți niște bani pentru a face acest lucru, așa că, dacă nu aveți sprijinul comunității, este puțin probabil să fiți de acord cu asta. Acest lucru se face pentru a preveni înregistrarea a milioane de microframework fără nicio reputație.

Membrii actuali:

Ce este PSR?

PSR (PHP Standards Recommendations) - recomandări standard, rezultatul muncii PHP-FIG. Unii membri ai Grupului propun reguli pentru fiecare PSR, în timp ce alții votează pentru susținerea sau eliminarea regulilor. Discuția are loc în Grupuri Google, iar seturile PSR sunt disponibile pe site-ul web oficial PHP-FIG.

Să ne uităm la câteva PSR-uri:

Primul pas către unificarea cadrelor este acela de a avea o structură comună de directoare, motiv pentru care a fost adoptat un standard comun de pornire.

  1. Spațiul de nume și clasa trebuie să aibă structura \\(\)*.
  2. Fiecare spațiu de nume trebuie să conțină un spațiu de nivel superior („Numele furnizorului”).
  3. Fiecare spațiu de nume poate avea câte niveluri se dorește.
  4. Fiecare separator de spațiu de nume este convertit în DIRECTORY_SEPARATOR când este încărcat.
  5. Fiecare caracter „_” din CLASS NAME este convertit în DIRECTORY_SEPARATOR.
  6. Spațiul de nume complet calificat și clasa sunt adăugate cu „.php” atunci când sunt încărcate.

Exemplu de funcție de încărcare automată:

PSR-1 - Standard de codare de bază

Aceste PSR-uri reglementează standardele de bază, ideea principală a cărora este că, dacă toți dezvoltatorii folosesc aceleași standarde, atunci codul poate fi portat fără probleme.

  1. Fișierele trebuie să utilizeze numai etichete
  2. Fișierele trebuie să utilizeze numai codificare UTF-8 fără BOM.
  3. Numele și clasele spațiilor trebuie să urmeze PSR-0.
  4. Numele claselor trebuie declarate în notația StudlyCaps.
  5. Constantele clasei trebuie declarate cu litere mari, separate prin liniuțe de subliniere.
  6. Metodele trebuie declarate în notație camelCase.

PSR-2 - Ghid de stil de codare

Acestea sunt instrucțiuni extinse pentru PSR-1 care descriu regulile de formatare a codului.

  1. Codul trebuie să respecte PSR-1.
  2. Ar trebui folosite 4 spații în loc de file.
  3. Nu ar trebui să existe o limită strictă a lungimii liniilor; lungimea recomandată este de până la 80 de caractere.
  4. Ar trebui să existe o linie goală după declarația spațiului de nume.
  5. Parantezele pentru clase ar trebui să se deschidă pe linia următoare după declarație și să se închidă după corpul clasei (la fel pentru metode).
  6. Trebuie definită vizibilitatea metodelor și proprietăților (publice, private).
  7. Parantezele de deschidere pentru structurile de control trebuie să fie pe aceeași linie, parantezele de închidere trebuie să fie pe linia următoare după corpul structurii.
  8. Spațiile nu sunt plasate după parantezele de deschidere ale metodelor structurii de control și înainte de parantezele de închidere.

PCR-3 - Interfață de înregistrare

PCR-3 reglementează înregistrarea, în special cele nouă metode principale.

  1. LoggerInterface oferă 8 metode pentru înregistrarea a opt niveluri RFC 5424 (depanare, notificare, avertizare, eroare, critică, alertă, urgență).
  2. A noua metodă log() ia nivelul de avertizare ca prim parametru. Apelarea unei metode cu un parametru de nivel de alertă trebuie să returneze același rezultat ca și apelarea unei metode la un anumit nivel de jurnal (log(ALERT) == alert()). Apelarea unei metode cu un nivel de avertizare nedefinit trebuie să arunce o excepție Psr\Log\InvalidArgumentException.

La fel ca PSR-0, PSR-4 oferă metode îmbunătățite de încărcare automată

  1. Termenul „clasă” se referă la clase, interfețe, trăsături și alte structuri similare
  2. Numele de clasă complet calificat are următoarea formă: \ (\)*\
  3. Când încărcați un fișier care corespunde unui nume de clasă complet calificat:
  • O serie învecinată de unul sau mai multe spații de nume principale, fără a număra delimitatorul de spațiu de nume principal, într-un nume de clasă complet calificat corespunde cel puțin unui „director rădăcină”.
  • Numele directoarelor și subdirectoarelor trebuie să se potrivească cu majuscule și minuscule ale spațiului de nume.
  • Sfârșitul numelui complet al clasei corespunde cu numele fișierului care se termină în .php. Lipsa numelui fișierului trebuie să se potrivească cu majuscule și minuscule ale sfârșitului numelui complet al clasei.
  • O implementare de încărcare automată nu trebuie să arunce excepții, să genereze erori de orice nivel și nu trebuie să returneze o valoare.

Concluzie

PHP-FIG schimbă modul în care sunt scrise cadrele, dar nu și modul în care funcționează. Clienții solicită adesea să lucrați cu codul existent într-un cadru sau să determinați cu ce cadru ar trebui să lucrați la un proiect. Recomandările PSR fac viața mult mai ușoară dezvoltatorilor în acest sens și asta e grozav!

limbaj de programare PHP a parcurs un drum lung de la un instrument pentru crearea de pagini personale la un limbaj de uz general. Astăzi este instalat pe milioane de servere din întreaga lume, folosit de milioane de dezvoltatori care creează o mare varietate de proiecte.

Este ușor de învățat și extrem de popular, mai ales printre începători. Prin urmare, dezvoltarea limbii a fost urmată de o dezvoltare puternică a comunității din jurul ei. Un număr mare de scripturi, pentru toate ocaziile, biblioteci diferite, cadre. Lipsa standardelor uniforme pentru proiectarea și scrierea codului a dus la apariția unui strat uriaș de produse informaționale construite pe principiile proprii ale dezvoltatorului acestui produs. Acest lucru a fost vizibil mai ales atunci când lucrați cu diverse cadre PHP, care a reprezentat multă vreme un ecosistem închis, incompatibil cu alte cadre, în ciuda faptului că sarcinile pe care le rezolvă sunt adesea asemănătoare.

În 2009, dezvoltatorii mai multor cadre au fost de acord să creeze o comunitate PHP Framework Interop Group (PHP-FIG), care ar dezvolta recomandări pentru dezvoltatori. Este important să subliniem că nu este vorba despre asta Standardele ISO, este mai corect să vorbim despre recomandări. Dar din moment ce cei care au creat PHP-FIG Deoarece comunitatea de dezvoltatori reprezintă cadre mari, recomandările lor au o greutate serioasă. A sustine Standarde PSR (recomandare standard PHP). permite compatibilitatea, ceea ce facilitează și accelerează dezvoltarea produsului final.

În total, la momentul scrierii, există 17 standarde, 9 dintre ele sunt aprobate, 8 sunt în faza de proiect, discutate activ, 1 standard nu este recomandat pentru utilizare.

Acum să trecem direct la descrierea fiecărui standard. Vă rugăm să rețineți că nu voi intra în detaliu despre fiecare standard aici, mai degrabă aceasta este o scurtă introducere. De asemenea, articolul le va lua în considerare doar pe acestea Standardele PSR, care sunt acceptate oficial, adică sunt în starea Acceptat.

PSR-1. Standard de codare de bază

Reprezintă regulile cele mai generale, cum ar fi, de exemplu, utilizarea Etichete PHP, codificarea fișierelor, separarea locului de declarare a funcției, clasa și locul utilizării acestora, denumirea claselor și metodelor.

PSR-2. Ghid de stil de cod

Este o continuare a primului standard și reglementează utilizarea filelor și a întreruperilor de linie în cod, lungimea maximă a liniilor de cod, regulile de proiectare a structurilor de control etc.

PSR-3. Interfață de înregistrare.

Acest standard este conceput pentru a permite (înregistrarea) logarea în aplicațiile în care sunt scrise PHP.

PSR-4. Standard de pornire

Acesta este probabil cel mai important și necesar standard, care va fi discutat într-un articol separat, detaliat. Clase care implementează PSR-4, poate fi încărcat de un singur autoloader, permițând pieselor și componentelor dintr-un cadru sau bibliotecă să fie folosite în alte proiecte.

PSR-6. Interfață de stocare în cache

Memorarea în cache este utilizată pentru a îmbunătăți performanța sistemului. ȘI PSR-6 vă permite să stocați și să preluați în mod standard date din cache folosind o interfață unificată.

PSR-7. Interfață de mesaje HTTP

Când scrieți mai mult sau mai puțin complex site-uri web în PHP, aproape întotdeauna trebuie să lucrezi cu Antete HTTP. Cu siguranță, limbaj PHP ne oferă opțiuni gata făcute pentru a lucra cu ei, cum ar fi matrice superglobală $_SERVER, funcții antet(), setcookie() etc., cu toate acestea, analiza lor manuală este plină de erori și nu este întotdeauna posibil să se țină cont de toate nuanțele lucrului cu ele. Și astfel, pentru a ușura munca dezvoltatorului, precum și pentru a face interfața pentru a interacționa cu Protocolul HTTP acest standard a fost adoptat. Voi vorbi mai detaliat despre acest standard într-unul din articolele următoare.

PSR-11. Interfață container

Când scriu programe PHP De multe ori trebuie să utilizați componente terțe. Și pentru a nu ne pierde în această pădure de dependențe, au fost inventate diverse metode de gestionare a dependențelor de cod, adesea incompatibile între ele, pe care acest standard le aduce la un numitor comun.

PSR-13. Link-uri hipermedia

Această interfață este concepută pentru a facilita dezvoltarea și utilizarea interfețelor de programare a aplicațiilor ( API).

PSR-14. Interfață simplă de stocare în cache

Este o continuare și îmbunătățire a standardului PSR-6

Astfel, astăzi ne-am uitat Standardele PSR. Pentru informații actualizate cu privire la stadiul standardelor, vă rugăm să contactați:

PHP poate fi numit pe deplin „limbajul de programare web al oamenilor” este foarte dificil să găsești un alt limbaj care ar putea concura cu el în condiții egale în ceea ce privește popularitatea sa. Am decis să cunosc oamenii din spatele dezvoltării sale, să răspund la întrebări stringente, să discut cele mai recente inovații și chiar să încerc să privesc viitorul internetului. Pentru a face acest lucru, ne-am întâlnit cu participanții legendari Echipa principală PHP, care supraveghează în mod direct dezvoltarea acestui limbaj și și-au câștigat o reputație ca experți mondiali recunoscuți în domeniul tehnologiilor web.

Deci, astăzi lideri dezvoltatori din Echipa principală PHP— (Andrei Zmievski), (Stas Malyshev), (Ilia Alshanetsky).

Pentru început, te rugăm să ne spui puțin despre tine - ce faci acum și unde lucrezi. Amintește-ți povestea cum ai venit în lumea programării.

SM: Acum locuiesc în SUA și lucrez într-o companie, lucrând la infrastructura acestui produs - i.e. acele părți ale sistemului care oferă baza pentru funcționalitatea generală și oferă o interfață pentru dezvoltarea modulelor specifice.

Dacă vorbim despre istoria venirii mele în programare, atunci m-am întors în școală, cu și din programele publicate în revistă „ Tehnologie - Tineret" Deși la început nu se putea numi programare - practic am introdus programe tipărite în revistă în memoria mașinii și am văzut ce s-a întâmplat. Dar apoi am vrut să învăț singur cum să fac această mașină complexă (la acea vreme) să facă ceea ce îmi doream și am început să-mi dau seama - pe cont propriu și cu ajutorul bătrânilor mei - cum a funcționat totul. A participat la cluburi, a petrecut ore întregi în bibliotecă citind reviste străine, a scris programe pentru plăcerea lui și apoi pentru bani. S-a dovedit că îmi place să fac computere utile și, spre marele meu noroc, o astfel de abilitate este foarte solicitată astăzi pe piața muncii.

Ar fi greu să enumer tot ceea ce m-a influențat pe această cale, dar cărțile au avut probabil cel mai mare efect asupra mea, în special lucrările (The Mythical Man-Month) și (The Inmates Are Running the Asylum - în traducerea rusă „Spitalul de psihiatrie”. în mâinile pacienţilor").

AZ: Locuiesc în San Francisco de 5 ani și cred că este cel mai frumos oraș din America. Lucrez pentru o companie. Deși acesta este un startup relativ tânăr, avem deja aproximativ 110-120 de angajați. O mare varietate de companii din întreaga lume folosesc produsul nostru pentru a-și monitoriza sistemele de afaceri și pentru a găsi rapid probleme. Avem și clienți mari, de exemplu, Netflix, Priceline și alții.

Cât despre povestea mea de dragoste cu programarea... cred că este mai probabil ca această profesie să te aleagă pe tine decât să o alegi tu. Îmi amintesc că când aveam 9 ani, am primit primul meu calculator programabil, dar și înainte de asta aveam înclinații notabile către matematică, logică și lucruri tehnice - din câte îmi amintesc, aceste abilități îmi erau inerente.

Ca un exemplu viu al modului în care a început totul, vă voi oferi o poveste din copilărie. Apoi, ca majoritatea copiilor sovietici, nu aveam propriul meu computer acasă, așa că mergeam în mod regulat la un centru de calculatoare, unde puteam închiria o mașină la oră și puteam lucra la BASIC și Pascal. Mergeam acolo de mai multe ori pe săptămână, dar într-o zi, sosind foarte devreme dimineața, m-am lăsat atât de purtat încât am căzut cu capul în cap într-un program care era interesant pentru mine și, în același timp, mi-am pierdut complet simțul timpului și am uitat. că era timpul să merg acasă.

M-am trezit doar când acest centru deja se închidea, la ora 22.00. Până atunci, părinții mei îmi sunaseră deja pe toți prietenii, profesorii etc. căutându-mă, dar din fericire au dat peste mine întorcându-mă din centru. Am fost lovit puternic pentru asta atunci, dar privind în urmă, înțeleg: de când îmi amintesc, am scris întotdeauna programe și am trăit în această lume parțial virtuală, așa că profesia mea actuală este pur și simplu o continuare a unei călătorii incitante care început în copilărie.

IN ABSENTA: Trăiesc și lucrez în Toronto, Canada.

Cât despre intrarea mea în programare, este încă surprinzător pentru mine. La începutul călătoriei mele, programarea era mai degrabă un hobby, cu excepția unui loc de muncă ciudat pe care l-am primit cumva pentru vară, legat de dezvoltarea la nivel scăzut în C. În tinerețe, nu mi-am propus niciodată în mod conștient obiective sau planuri pentru a face acest lucru profesional. În timp ce mă chinuiam în mod amator cu programele mele C, am fost odată implicat în prima mea dezvoltare web personalizată, care a fost făcută în Perl. Aici începe călătoria mea către Internet și specializarea mea în programare web.

Din păcate, pe măsură ce acest proiect Perl a crescut, nu mi-a plăcut din ce în ce mai mult inconsecvența acestui limbaj, iar compania de găzduire care mă servea la acea vreme, „chinuită” de mine, s-a oferit într-o zi ea însăși să încerce PHP, care era nou pentru asta. timp. Mi-a plăcut imediat acest limbaj pentru că era mai bine structurat și mai apropiat în sintaxa sa de iubitul meu C. Documentație online excelentă - mi-am finalizat migrarea rapidă și finală la ea.


Ilya Alshanetsky

Am început să folosesc PHP 3 atât de activ încât au început să apară treptat propriile mele dezvoltări, extinzându-și capacitățile, pe care am început să le ofer în mod regulat pe canalul IRC creatorului său Rasmus. Au fost atât de multe patch-uri și remedieri de la mine, încât s-a săturat repede de ele și mi-a dat acces direct CVS la depozitul de proiecte. De atunci, s-au scris și s-au făcut multe, chiar am avut ocazia să fiu manager de lansare (PHP release master) pentru versiunile sale populare 4.3, 5.1 și 5.2.

Apropo, în paralel cu această activitate, a existat multă muncă de consultanță pentru clienții comerciali externi, pentru care uneori probleme foarte extraordinare cu performanța, scalabilitatea și securitatea propriilor proiecte create în PHP au fost rezolvate în mod privat. Într-una dintre aceste consultări, am ajuns atât de adânc cufundat în proiectul lor, încât am ajuns să devin partener în această companie (Centah Inc.) și am primit funcția de CIO, unde lucrez în prezent.

Cum ați intrat în echipa PHP Core, ce cale ați urmat pentru a ajunge acolo?

AZ: Permiteți-mi să răspund cu propriul meu exemplu, dar mai întâi puțină istorie. Am început să lucrez cu PHP în jurul anului 1998, apoi a fost PHP 3, una dintre versiunile anterioare. Rescriem un proiect mare dintr-o altă limbă în PHP și aveam nevoie să găsesc suport pentru acum aproape uitat. Nu am găsit o astfel de bibliotecă, dar mi-a plăcut foarte mult că PHP are documentație și API excelente, așa că am decis să-mi scriu propria extensie. Când am terminat, l-am trimis imediat pe lista de corespondență PHP. Și în mod neașteptat pentru mine, au decis să-l adauge la următoarea versiune a limbii.

Ulterior, mi s-a dat acces la CVS și am început să repar erori, să scriu mai multe funcții diferite etc. Până la sfârșitul anului 1999, am fost unul dintre cei mai activi membri ai grupului, apoi mi-am propus să organizez prima întâlnire a dezvoltatorilor PHP din Israel pentru a discuta despre viitorul limbii și m-am inclus în această listă de corespondență. Deci nu s-a votat, s-a întâmplat că am intrat imediat Echipa principală PHP.


Rasmus Lerdorf, creatorul PHP

Acest tip de încredere și deschidere m-au motivat să lucrez din ce în ce mai mult la codul PHP. După WDDX, am lucrat la un modul de sesiune, apoi am scris o grămadă de funcții pentru a lucra cu matrice, apoi am decis că PHP trebuie să aibă expresii regulate similare cu Perl, așa că am creat un modul PCRE. Până atunci, PHP 4 fusese lansat de mult, dar am fost foarte enervat de unele probleme legate de modul în care funcționau obiectele și clasele (sau mai degrabă nu funcționau). În această chestiune, am avut o corespondență lungă cu Andi și Zeev, care au creat , iar acest lucru a dus la un sprijin fundamental nou Programare orientată pe obiecteîn noul PHP 5 de atunci.

După aceea, am lucrat în principal la codul pentru Zend Engine în sine și am făcut, de asemenea, un nou modul de tokenizer. Din 2003, împreună cu Rasmus, și acolo am lansat un proiect pentru a sprijini Unicode în PHP, dar asta pentru altă dată...

Ce crezi că este vorba despre PHP care l-a făcut atât de popular?

AZ: Se întâmplă că în momentul de față scriu un proiect în C++ și Python, așa că voi răspunde pe baza acestei experiențe comparative, arătând parcă din acest „clopotniță diferită”.

Principalul lucru pentru mine este că PHP are un API bogat și extins, cu ajutorul căruia puteți extinde limbajul în multe direcții, chiar uneori neașteptate. Pe de altă parte, aud adesea de la oameni cât de ușor le-a fost să înceapă să folosească PHP și cât de mult le place că poți scrie un site web sau un program în câteva ore. Aceasta este esența PHP: este atât complex, cât și simplu, de modă veche și modern, original și împrumut idei din afara lumii - este doar foarte versatil.

Erorile de securitate sunt o durere de cap majoră pentru programatorii web și mulți utilizatori ai produselor lor. Privind înapoi la experiența dumneavoastră extinsă, care sunt cele mai importante și tipice probleme de securitate cu PHP și dezvoltatorii săi? Puteți da vreun sfat pentru edificarea tinerilor programatori PHP?

SM: Una dintre principalele lecții, cred, este că securitatea codului nu este o calitate care poate fi insuflată extern, independent de restul codului. În ceea ce privește siguranța ar trebui să fie o parte zilnică a muncii, din primul minut, de la proiectare până la lansarea produsului finit. Au fost făcute mai multe încercări de a adăuga caracteristici de securitate „din exterior” în PHP - dar experiența a arătat că aceste încercări, fără vigilență constantă din partea programatorului, sunt sortite eșecului. Platforma îl poate ajuta doar să monitorizeze securitatea codului, dar nu poate garanta această securitate fără efort din partea lui.

Prin urmare, sfatul principal ar fi următorul - nu aveți încredere niciodată în nicio dată externă sau în date asupra cărora este posibil controlul din exterior. 99% dintre problemele de securitate apar deoarece presupunerile făcute cu privire la datele de intrare se dovedesc a fi incorecte, iar atunci când are loc un atac ulterior, codul se comportă diferit decât intenționează dezvoltatorul. Prin urmare, dezvoltați obiceiul de a vă întreba mereu - „ce se întâmplă dacă acest parametru se schimbă într-un mod neașteptat? Ce se întâmplă dacă acest argument nu este aplicat conform intenției?” Și testează-ți codul în consecință.

Următoarea mea recomandare este ca, în loc să verifici „dacă există ceva ilegal în date”, să transformi datele în mod proactiv, astfel încât să fie garantat că vor fi așa cum ar trebui. Acest lucru va face mult mai ușor să evitați greșelile. De asemenea, nu vă bazați pe alte părți ale codului dvs. pentru a avea grijă de securitate - de exemplu, dacă faceți o interogare dinamică a bazei de date, asigurați-vă întotdeauna că parametrii și interogarea sunt generate și filtrate în așa fel încât injecție sql este imposibil - chiar dacă sunteți sigur că datele sunt filtrate în altă parte (de exemplu, la nivel de cadru). Apoi, dacă codul extern este modificat în așa fel încât datele nefiltrate să intre brusc în procedura dvs., vulnerabilitatea tot nu va apărea.

Creșterea explozivă a aplicațiilor mobile va continua probabil, dar multe dintre ele vor trece la HTML5 ca platformă universală. În acest sens, va fi nevoie să se dezvolte protocoale de sincronizare a datelor, precum și să se dezvolte modele care să permită lucrul simultan atât cu browsere tradiționale, cât și cu diferiți clienți de telefonie mobilă, adesea cu capacități diferite.

În general, browserul va deveni în sfârșit o parte cu drepturi depline a infrastructurii web și, prin urmare, unele dintre responsabilitățile îndeplinite în prezent de server se vor transfera în partea clientului. Prin urmare, aș sfătui persoanele care lucrează în prezent cu PHP să țină pasul cu cele mai recente evoluții în Javascript, HTML5, CSS3 etc.

Le mulțumesc membrilor Echipa principală PHP, care, în ciuda faptului că a fost foarte ocupat, și-a făcut cu amabilitate timp să răspundă la întrebări pentru cititorii noștri.

Personaje:


Andrei Zmievski, unul dintre curatori Proiect PHP, dezvoltator Zend Engine, creator de proiecte și coautor al popularului manual, autor al implementărilor Unicode și OOP în PHP. În timpul liber îi place sportul, prepararea berii acasă și gătitul. Îi place mult să citească și să călătorească.

Stas Malyshev, participant Proiect PHP din 2000, manager de lansare a versiunii PHP 5.4, participant la multe proiecte OpenSource. În timpul liber, jocurile intelectuale (versiunea sportivă a „Ce? Unde? Când?”, „Inelul creierului”) și aikido.

Ilya Alshanetsky, expert în securitate și unul dintre cei mai vechi dezvoltatori PHP, șef, manager de lansare al versiunilor PHP 4.3, 5.1, 5.2, creator al motorului de forum, participant activ la multe proiecte OpenSource. și pe tema securității programării web.

p.s.: Promit că în noul an 2013 voi posta multe dintre interviurile mele VIP cu cei mai importanți dezvoltatori din lume - să rămână secrete pentru moment.

16.09.2016

Să încercăm să determinăm cum să creștem performanța unui server de aplicații bazat pe php-fpm și, de asemenea, să creăm o listă de verificare pentru verificarea configurației procesului fpm.

În primul rând, ar trebui să determinați locația fișierului de configurare a pool-ului. Dacă ați instalat php-fpm din depozitul de sistem, atunci configurația pool-ului www va fi localizat aproximativ aici /etc/php5/fpm/pool.d/www.conf . Dacă utilizați propria versiune sau un alt sistem de operare (nu Debian), ar trebui să căutați locația fișierului în documentație sau să o specificați manual.

Să încercăm să privim configurația mai detaliat.

Trecerea la socket-uri UNIX

Probabil că primul lucru la care ar trebui să acordați atenție este modul în care datele circulă de la serverul web la procesele dvs. PHP. Acest lucru se reflectă în directiva de ascultare:

asculta = 127.0.0.1:9000

Dacă adresa:port este setată, atunci datele trec prin stiva TCP, iar acest lucru probabil nu este foarte bun. Dacă există o cale către socket, de exemplu:

asculta = /var/run/php5-fpm.sock

apoi datele trec printr-un socket Unix și puteți sări peste această secțiune.

De ce mai merită să treci la un socket Unix? UDS (unix domain socket), spre deosebire de comunicarea prin stiva TCP, are avantaje semnificative:

  • nu necesită schimbarea contextului, UDS folosește netisr)
  • Datagrama UDS este scrisă direct în socket-ul de destinație
  • trimiterea unei datagrame UDS necesită mai puține operațiuni (fără sume de control, fără antete TCP, fără rutare)

Latență medie TCP: 6 us Latență medie UDS: 2 us Latență medie PIPE: 2 us Debit mediu TCP: 253702 msg/s Debit mediu UDS: 1733874 msg/s Debit mediu PIPE: 1682796 msg/s

Astfel, UDS are o întârziere de ~66% mai puținși debitul în de 7 ori mai mult TCP. Prin urmare, cel mai probabil merită să treceți la UDS. În cazul meu, socket-ul va fi localizat la /var/run/php5-fpm.sock.

; Să comentăm asta - ascultă = 127.0.0.1:9000 ascultă = /var/run/php5-fpm.sock

De asemenea, ar trebui să vă asigurați că serverul web (sau orice alt proces care trebuie să comunice) are acces de citire/scriere la socket. Există setări pentru asta asculta.grupȘi ascultare.modul Cel mai simplu mod este să rulezi ambele procese de la același utilizator sau grup, în cazul nostru php-fpm și serverul web vor fi lansate cu grupul www-data:

listen.owner = www-data listen.group = www-data listen.mode = 0660

Verificarea mecanismului de procesare a evenimentului selectat

Pentru a lucra eficient cu I/O (descriptori de intrare/ieșire, fișier/dispozitiv/socket), merită să verificați dacă setarea este specificată corect evenimente.mecanism. Dacă php-fpm este instalat din depozitul de sistem, cel mai probabil totul este în regulă acolo - fie nu este specificat (instalat automat) fie specificat corect.

Semnificația sa depinde de sistemul de operare, pentru care există un indiciu în documentație:

; - epoll (linux >= 2.5.44) ; - kqueue (FreeBSD >= 4.1, OpenBSD >= 2.9, NetBSD >= 2.0); - /dev/poll (Solaris >= 7) ; - port (Solaris >= 10)

De exemplu, dacă lucrăm la o distribuție Linux modernă, avem nevoie de epool:

evenimente.mecanism = epoll

Selectarea unui tip de pool - dinamic / static / la cerere

De asemenea, merită să acordați atenție setărilor managerului de proces (pm). În esență, acesta este procesul principal, care își va gestiona toți copiii (care execută codul aplicației) după o anumită logică, care este de fapt descrisă în fișierul de configurare.

Există un total de 3 scheme de control al procesului disponibile:

  • dinamic
  • static
  • la cerere

Cel mai simplu este static. Modul de funcționare este următorul: lansați un număr fix de procese copil și mențineți-le în stare de funcționare. Această schemă de operare nu este foarte eficientă, deoarece numărul de solicitări și încărcarea acestora se pot schimba din când în când, dar numărul de procese copii nu - ele ocupă întotdeauna o anumită cantitate de RAM și nu pot procesa sarcinile de vârf într-o coadă.

dinamic un pool va rezolva această problemă, reglează numărul de procese copil pe baza valorilor fișierului de configurare, modificându-le în sus sau în jos, în funcție de încărcare. Acest pool este cel mai potrivit pentru un server de aplicații care necesită un răspuns rapid la solicitări, lucrează cu sarcini de vârf și necesită economisirea resurselor (prin reducerea proceselor copil atunci când este inactiv).

la cerere piscina este foarte asemanatoare cu static, dar nu lansează procese secundare când începe procesul principal. Numai la sosirea primei cereri va fi creat primul proces copil, iar după un anumit timp de așteptare (specificat în configurație) va fi distrus. Prin urmare, este relevant pentru serverele cu resurse limitate sau pentru logica care nu necesită răspuns rapid.

Scurgeri de memorie și criminal OOM

Ar trebui să acordați atenție calității aplicațiilor care vor fi executate de procesele copil. Dacă calitatea aplicației nu este foarte ridicată sau sunt utilizate multe biblioteci terțe, atunci trebuie să vă gândiți la posibile scurgeri de memorie și să setați valorile unor astfel de variabile:

  • pm.max_requests
  • request_terminate_timeout

pm.max_requests acesta este numărul maxim de solicitări pe care le va procesa copilul înainte de a fi ucis. Distrugerea forțată a procesului vă permite să evitați o situație în care memoria procesului copil „se umflă” din cauza scurgerilor (deoarece procesul continuă să funcționeze după solicitare după solicitare). Pe de altă parte, o valoare prea mică va duce la reporniri frecvente, ducând la pierderi de performanță. Merită să începeți cu o valoare de 1000 și apoi să micșorați sau să creșteți această valoare.

request_terminate_timeout setează perioada maximă de timp pe care un proces copil poate rula înainte de a fi oprit. Acest lucru vă permite să evitați interogările lungi dacă din anumite motive valoarea max_execution_time din setările interpretului a fost modificată. Valoarea ar trebui să fie setată pe baza logicii aplicațiilor care sunt procesate, să zicem anii 60(1 minut).

Crearea unui bazin dinamic

Pentru serverul principal de aplicații, datorită avantajelor evidente, se alege adesea un pool dinamic. Funcționarea sa este descrisă de următoarele setări:

  • pm.max_copii- numărul maxim de procese copil
  • pm.start_servers- numărul de procese la pornire
  • pm.min_spare_servers- numărul minim de procese care așteaptă conexiuni (cereri de procesare)
  • pm.max_spare_servers- numărul maxim de procese care așteaptă conexiuni (cererile care urmează să fie procesate)

Pentru a seta corect aceste valori, este necesar să luați în considerare:

  • câtă memorie consumă în medie un proces copil?
  • cantitatea de RAM disponibilă

Puteți afla valoarea medie a memoriei per proces php-fpm pe o aplicație care rulează deja folosind planificatorul:

# ps -ylC php-fpm --sort:rss S UID PID PPID C PRI NI RSS SZ WCHAN TTY TIME CMD S 0 1445 1 0 80 0 9552 42588 ep_pol ? 00:00:00 php5-fpm

Avem nevoie de valoarea medie din coloana RSS (dimensiunea memoriei rezidente în kiloocteți). În cazul meu este de ~20MB. Dacă nu există încărcare pe aplicații, puteți utiliza Apache Benchmark pentru a crea o încărcare simplă pe php-fpm.

Cantitatea de memorie totală/disponibilă/utilizată poate fi vizualizată folosind gratuit:

# liber -m total folosit liber ... Memorie: 4096 600 3496

Total de procese maxime = (Total Ram - (Used Ram + Buffer)) / (Memorie per proces php) Total RAM: 4GB RAM folosit: 1000MB Buffer de securitate: 400MB Memorie per copil proces php-fpm (în medie): 30MB Număr maxim posibil de procese = (4096 - (1000 + 400)) / 30 = 89 Număr par: 89 rotunjit la 80

Valoarea directivelor rămase poate fi setată în funcție de încărcarea așteptată a aplicației și, de asemenea, poate lua în considerare ce altceva face serverul în afară de rularea php-fpm (de exemplu, SGBD-ul necesită și resurse). Dacă există multe sarcini pe server, merită să reduceți numărul de procese inițiale / maxime.

De exemplu, să luăm în considerare faptul că există 2 pool-uri www1 și www2 pe server (de exemplu, 2 resurse web), atunci configurația fiecăruia dintre ele poate arăta astfel:

pm.max_copii = 40 ; 80 / 2 pm.start_servers = 15 pm.min_spare_servers = 15 pm.max_spare_servers = 25