Бавната PHP апликација ретко има една драматична мана. Почесто, таа губи време во мали, повторливи моменти: подигнување код што барањето не го потребува, прерано отворање врски, вчитување премногу конфигурација, извршување избегливи прашања или задржување работник додека надворешна услуга се двоуми.

Разбирањето на животниот циклус на барањето ги прави тие трошоци видливи. Тоа ја претвора работата на перформансите од збир на фолклорни поправки во практична вежба: следете едно барање од пристигнувањето до одговорот, измерете ја секоја фаза и отстранете ја работата што не припаѓа таму.

Почнете со патеката што барањето навистина ја поминува

Во типична PHP поставеност, веб-сервер како Nginx или Apache прима HTTP барање и ги препраќа подобните динамички барања до PHP. Со PHP-FPM, тоа обично значи доделување на барањето на достапен работнички процес. Работникот ја извршува влезната точка на апликацијата, испраќа одговор и станува достапен за друго барање.

Деталите на рамките се разликуваат, но широкиот животен циклус е познат:

1. Веб-серверот директно опслужува статички датотеки или го препраќа барањето до PHP.
2. PHP работник почнува да го обработува барањето и ја вчитува влезната точка на апликацијата.
3. Кодот за подигнување вчитува конфигурација, регистрира автоматско вчитување, иницијализира услуги и го гради контекстот на барањето.
4. Рутирањето и посредничкиот софтвер одлучуваат што треба да го обработи барањето.
5. Кодот на апликацијата чита или менува податоци и може да повикува надворешни услуги.
6. Апликацијата создава одговор, кој посредничкиот софтвер може да го измени пред да биде испратен.
7. Се извршува чистење и работникот се враќа во PHP-FPM базенот.

Оваа низа е важна бидејќи секое барање плаќа за работата извршена пред да може да се произведе одговор. Брз контролер не може да надомести за фаза на подигнување што вчитува непотребни услуги или за слој на база на податоци што создава врски за крајни точки кои никогаш не бараат податоци.

Држете ја статичката работа надвор од PHP

Првата оптимизација е архитектонска, а не PHP микрооптимизација. Сликите, CSS, JavaScript, преземањата и кешираните јавни средства вообичаено треба да ги опслужува веб-серверот или CDN. Испраќањето низ преден контролер троши PHP работници за работа што извршувачката околина не треба да ја извршува.

Внимателно рутирајте го веб-серверот, така што само патеките на апликацијата да стигнуваат до PHP. Ова го намалува притисокот врз работниците и го подобрува однесувањето на динамичкиот сообраќај при скокови. Исто така го појаснува планирањето капацитет: ограничувањата на PHP работниците може да ги одразуваат вистинските барања на апликацијата, наместо секое средство на кое страницата случајно упатува.

Направете го подигнувањето пропорционално на крајната точка

Кодот за подигнување лесно се занемарува бидејќи е споделен. Токму затоа заслужува внимание: мал трошок помножен со секое барање може да доминира во зафатена услуга.

Автоматското вчитување генерално е правилниот стандард, но избегнувајте нетрпеливо вчитување широки множества класи „за секој случај“. Исто така, конфигурацијата треба да се кешира или компајлира кога рамката го поддржува тоа, притоа зачувувајќи сигурен процес на распоредување за повторно градење на тој кеш по промени во конфигурацијата.

Контејнерите за услуги ја заслужуваат истата дисциплина. Зависност може да се регистрира без да биде веднаш инстанцирана. Претпочитајте мрзливо создавање кога услугата е скапа, а само некои рути ја бараат. На пример, проверка на здравјето не треба да иницијализира клиент за пошта, интеграција за пребарување или сложена услуга за известување.

Целта не е секоја зависност да биде мрзлива. Таа е да се осигури дека секое барање плаќа само за можностите што ги користи.

Користете посреднички софтвер како граница на трошок

Посредничкиот софтвер е вреден за автентикација, евидентирање, ограничување на стапката, закупништво, локализација и заглавија на одговори. Исто така може да стане невидлив данок кога глобалниот посреднички софтвер извршува прашања до база на податоци, интроспекција на токени или далечински повици за рути што не ги бараат.

Класифицирајте го посредничкиот софтвер според опфат:

• Глобалниот посреднички софтвер треба да биде евтин и универзално неопходен.
• Посредничкиот софтвер за групи рути треба да поддржува значајна класа крајни точки.
• Посредничкиот софтвер за конкретни рути треба да ги заштитува или збогатува само крајните точки што го потребуваат.

Ова е особено важно за API крајни точки што треба да останат брзи под оптоварување. Автентикацијата може да е неизбежна, но проверката на овластување, преземањето конфигурација на закупец и евалуацијата на ознаки за функции не мора сите да се случуваат пред секоја јавна крајна точка.

Времето на базата на податоци е дел од времето на барањето

Поголемиот дел од доцнењето на апликацијата не се троши на извршување PHP инструкции. Најчесто се троши на чекање: на база на податоци, кеш, мрежа, диск или друга услуга. Базата на податоци често е најзначајната зависност бидејќи кодот на апликацијата може да претвори една логичка страница во десетици прашања, без тој трошок да биде очигледен.

Почнете со набљудување на бројот и времетраењето на прашањата по крајна точка. Барајте повторени прашања во циклуси, недостасувачки индекси на вообичаени филтри и спојувања, и прашања што враќаат многу повеќе колони или редови отколку што му се потребни на одговорот. Поправањето на образец на N+1 прашања обично е повредно од подесувањето мал циклус во PHP.

Ракувањето со врски исто така припаѓа во размислувањето за животниот циклус. Создавањето врска има трошок, но задржувањето премногу неактивни врски може да го исцрпи капацитетот на базата на податоци. Поставете ги бројот на PHP-FPM работници имајќи го предвид буџетот за врски со базата на податоци. Ако секој работник може да држи врска со база на податоци, максималниот број работници мора да биде безбеден за базата на податоци, не само за CPU и меморијата.

Кеширајте само откако ќе ја идентификувате повторената скапа работа. Кешот може да заштити база на податоци од сообраќај богат со читања, но исто така воведува поништување, однесување со застарени податоци и режими на неуспех. Дефинирајте што треба да направи апликацијата кога кешот е недостапен: да не успее барањето, да се врати на базата на податоци или да послужи ограничен одговор. Таа одлука треба да биде намерна.

Заштитете ги работниците од бавни зависности

PHP-FPM работникот е зафатен додека не заврши барањето. Ако надворешен API заглави, работникот чека. При доволно истовремени бавни барања, базенот може да се наполни и здравите барања почнуваат да чекаат во ред зад нездравите.

Секоја излезна зависност има потреба од ограничено однесување. Поставете временски ограничувања за поврзување и вкупно време, експлицитно ракувајте со неуспешни одговори и избегнувајте автоматски повторувања што го умножуваат сообраќајот за време на прекин. Кога повторувањето е соодветно, треба да биде ограничено, да се применува само на безбедни операции и да биде дизајнирано имајќи ја предвид идемпотентноста.

$response = $client->request('GET', $url, [
    'connect_timeout' => 1.0,
    'timeout' => 3.0,
]);

Точните опции на клиентот варираат според библиотеката, затоа сметајте го ова за образец, а не за договор за копирање и вметнување. Важниот дел е дека излезниот повик има јасна горна граница и корисна резервна патека.

За работа што не мора да заврши пред корисникот да добие одговор, користете редица или друг асинхрон механизам. Испорака на е-пошта, генерирање минијатури, создавање извештаи и некритични известувања се вообичаени кандидати. Задржете го барањето одговорно за валидација и евидентирање на намерата; нека работникот ја обработи побавната дополнителна задача.

PHP-FPM и распоредувањето се карактеристики за перформанси

Конфигурацијата на извршувачката околина е дел од перформансите на апликацијата. PHP-FPM базен со премалку работници создава редици дури и кога машината има слободни ресурси. Премногу работници може да предизвикаат притисок врз меморијата, прекумерни врски со базата на податоци и CPU конкуренција. Правилниот број зависи од меморијата по работник, времетраењето на барањата, обликот на сообраќајот и ограничувањата надолу по системот.

Мерете пред да ги менувате поставките на базенот. Набљудувајте ги заедно чекањето во ред за барања, искористеноста на работниците, користењето меморија, стапките на грешки и оптоварувањето на базата на податоци. Поголем базен може накратко да скрие бавна зависност, додека го прави евентуалниот неуспех поширок.

Во продукција, овозможете и одржувајте го PHP кешот за опкод. Тој избегнува повторно парсирање и компајлирање на PHP изворот при секое барање. Распоредувањата исто така треба да бидат дизајнирани така што генерираната конфигурација, кешовите на рути и метаподатоците за автоматско вчитување да одговараат на објавениот код. Кешовите за перформанси што се застарени по распоредувањето се грешки во сигурноста облечени како оптимизација.

Мерете го животниот циклус, не само крајната точка

Корисна истрага за перформансите следи барање преку границите: временски мерења на веб-серверот, време на PHP извршување, прашања до база на податоци, операции со кешот, однесување на редицата и излезни повици. Идентификаторите за корелација и структурираните дневници ја олеснуваат реконструкцијата на таа патека, особено кога навидум бавна крајна точка всушност чека на друг систем.

Најпрво фокусирајте се на рутите со висок сообраќај и висока латентност. Воспоставете основна линија, направете една значајна промена и проверете ги и латентноста и исправноста. Одговор што е брз затоа што прескокнал овластување, неочекувано вратил застарени податоци или испуштил спореден ефект не е оптимизација.

Перформансите се дисциплиниран дизајн на барања

Најсилните добивки во PHP перформансите доаѓаат од третирањето на секое барање како буџет. Послужете статички средства без PHP. Подигнете само што бара рутата. Одржувајте ги прашањата намерни. Ограничете ја секоја зависност. Преместете ја несуштинската работа надвор од критичната патека. Димензионирајте ги работниците според системите од кои зависат.

Кога животниот циклус е јасен, перформансите престануваат да бидат мистериозни. За секое барање станува полесно да се расудува, полесно да се измери и многу потешко случајно да се направи скапо.