PHP ima reputaciju da radi jednu stvar odjednom: primi zahtjev, izradi odgovor, nestane. Taj je model i dalje izuzetno učinkovit za mnoge aplikacije. Problemi počinju kada zahtjev većinu svojeg vremena provede čekajući — HTTP uslugu, bazu podataka, predmemoriju ili sporu operaciju datotečnog sustava. Radnik koji čeka ne obavlja koristan posao, a pod opterećenjem se ta čekanja gomilaju u redove i frustrirajuću latenciju.

Asinkroni PHP nije u tome da svaki redak koda učinite pametnim. Riječ je o prepoznavanju neovisnih razdoblja čekanja i omogućavanju nastavka korisnog rada dok se ona ne razriješe. Ako se primijeni pažljivo, može učiniti pozadinske usluge responzivnijima bez žrtvovanja jasnoće zbog koje je PHP produktivan.

Razumijte problem prije odabira asinkronog alata

Asinkrono izvršavanje najviše pomaže kada je rad ograničen I/O-om. Pozivanje nekoliko neovisnih usluga, dohvaćanje više udaljenih resursa ili strujanje podataka klijentu tipični su primjeri. Ono ne čini CPU-intenzivnu transformaciju slike, izračun izvještaja ili zadatak šifriranja inherentno bržim na jednoj CPU jezgri.

Ta je razlika važna. Ako krajnja točka obavlja skupe izračune, premjestite ih u pozadinskog radnika, optimizirajte algoritam ili dodajte kapacitet. Ako čeka tri nepovezana mrežna poziva, konkurentnost može smanjiti ukupno vrijeme na satu prema trajanju najsporijeg poziva, umjesto zbroja sva tri.

Počnite s vremenskom crtom zahtjeva. Navedite svaku izlaznu ovisnost, njezino vremensko ograničenje, ovisi li o drugom rezultatu i što se treba dogoditi kada ne uspije. Ova vježba često otkriva jednostavnije poboljšanje od uvođenja novog modela izvođenja: uklonite nepotreban poziv, predmemorirajte stabilne podatke ili omogućite da nizvodni API vraća polja koja su stvarno potrebna.

Koristite konkurentnost tamo gdje su ovisnosti doista neovisne

Koristan prvi korak su konkurentni HTTP zahtjevi. PHP-ovo cURL multi sučelje može upravljati višestrukim prijenosima bez potrebe za radnim okvirom. Primjer u nastavku dohvaća dvije neovisne krajnje točke i zadržava tijelo odgovora za svaki rukovatelj.

<?php

$urls = [
    'profile' => 'https://api.example.test/profile/42',
    'orders' => 'https://api.example.test/orders?customer=42',
];

$multi = curl_multi_init();
$handles = [];

foreach ($urls as $name => $url) {
    $handle = curl_init($url);
    curl_setopt_array($handle, [
        CURLOPT_RETURNTRANSFER => true,
        CURLOPT_CONNECTTIMEOUT => 2,
        CURLOPT_TIMEOUT => 5,
    ]);

    $handles[$name] = $handle;
    curl_multi_add_handle($multi, $handle);
}

do {
    $status = curl_multi_exec($multi, $running);
    if ($running) {
        curl_multi_select($multi, 1.0);
    }
} while ($running && $status === CURLM_OK);

$responses = [];

foreach ($handles as $name => $handle) {
    $body = curl_multi_getcontent($handle);
    $error = curl_error($handle);

    $responses[$name] = $error === '' ? $body : null;

    curl_multi_remove_handle($multi, $handle);
    curl_close($handle);
}

curl_multi_close($multi);

Kod je namjerno jednostavan, ali produkcijski aspekti nisu. Provjerite HTTP statusne kodove kao i pogreške prijenosa, dekodirajte i provjerite podatke odgovora te odlučite koji je rezultat obavezan. Stranica profila može se prikazati bez preporuka; potvrda plaćanja ne bi trebala nastaviti ako je njezin obavezni odgovor autorizacije neizvjestan.

Biblioteke za petlju događaja i asinkroni radni okviri mogu ponuditi strukturiraniji model za veće usluge, uključujući mjerače vremena, neblokirajuće tokove, obećanja i otkazivanje. Moderni PHP također pruža Fibers, koji bibliotekama omogućuju pauziranje i nastavak izvršavanja u kooperativnom stilu. Fibers su gradivni blok, a ne sami po sebi petlja događaja ili prekidač za performanse. Odaberite biblioteku ili radni okvir samo kada njegov životni ciklus, model implementacije i poznavanje tima odgovaraju usluzi.

Vremenska ograničenja, limiti i zamjensko ponašanje pravi su dizajn

Konkurentnost povećava broj operacija u tijeku. Bez ograničenja, prometna krajnja točka može sporu nizvodnu ovisnost pretvoriti u oluju veza. Svaki izlazni poziv treba vremensko ograničenje povezivanja, ukupni rok i ograničenu politiku ponovnih pokušaja. Trenutačno i neograničeno ponovno pokušavanje nije otpornost; to je način da se prekid rada pojača.

• Postavite rok za zahtjev. Raspodijelite vrijeme između nizvodnih poziva umjesto da svakome dopustite potrošiti cijeli životni vijek zahtjeva.
• Ograničite konkurentnost. Obrađujte velike skupove u malim grupama kako bi deskriptori datoteka, utičnice i udaljene usluge ostali zaštićeni.
• Ponavljajte selektivno. Pokušajte ponovno samo privremene neuspjehe kada je operaciju sigurno ponoviti i koristite odgodu s varijacijom.
• Definirajte postupnu degradaciju. Vratite predmemorirane, djelomične ili odgođene rezultate samo kada to ponašanje proizvoda dopušta.
• Očuvajte vidljivost. Prosljeđujte ID-jeve zahtjeva i bilježite vrijeme ovisnosti, neuspjehe i razloge vremenskih ograničenja.

Idempotentnost zaslužuje posebnu pozornost. Neuspješno čitanje često se može ponoviti. Zahtjev koji stvara narudžbu, šalje e-poštu ili naplaćuje karticu možda je uspio čak i ako klijent nikada nije primio odgovor. Upotrijebite ključ idempotentnosti ili drugi mehanizam deduplikacije na strani poslužitelja prije dodavanja automatskih ponovnih pokušaja operacijama sa sporednim učincima.

Neka rad s bazom podataka bude jednostavan i pouzdan

Veze s bazom podataka nisu besplatne, a asinkrona aplikacija može stvarati pritisak brže od tradicionalne implementacije s jednim zahtjevom po procesu. Izbjegavajte istodobno izdavanje nekoliko upita samo zato što je to moguće. Najprije smanjite povratna putovanja odgovarajućim indeksima, dobro oblikovanim upitima i promišljenim grupiranjem. Zatim koristite konkurentnost za neovisan vanjski rad oko baze podataka kada poboljšava putanju zahtjeva.

Transakcije trebaju ostati kratke i usredotočene. Nemojte držati transakciju otvorenom dok čekate udaljeni API ako se tijek rada može redizajnirati. Sigurniji je obrazac potvrditi lokalno stanje, po potrebi zabilježiti outbox događaj u istoj transakciji i prepustiti radniku vanjsku isporuku s logikom ponovnog pokušaja i deduplikacije.

Implementacija mijenja odgovor

Tradicionalne PHP-FPM implementacije jasno izoliraju svaki zahtjev. Dugotrajni radnici, petlje događaja i aplikacijski poslužitelji održavaju proces živim, što može poboljšati propusnost za I/O-intenzivna radna opterećenja, ali uvodi odgovornosti životnog ciklusa. Resetirajte stanje specifično za zahtjev, zatvorite ili oslobodite resurse, obradite graciozno gašenje i planirajte recikliranje radnika nakon curenja ili neočekivanog rasta.

Kontejneri čine te probleme vidljivima. Konfigurirajte provjere zdravlja koje odražavaju može li proces posluživati promet, proslijedite signale gašenja kroz ulaznu točku kontejnera i dajte radnicima dovoljno vremena da završe ili sigurno napuste rad u tijeku tijekom implementacije. Obradu web zahtjeva i dugotrajne pozadinske potrošače držite kao zasebne uloge procesa, čak i ako dijele sliku i bazu koda.

Mjerite rezultat vidljiv korisniku

Asinkroni kod vrijedi samo kada poboljšava vidljivo ograničenje: latenciju, propusnost, učinkovitost veza ili pouzdanost integracije. Mjerite percentilna vremena odgovora, dubinu reda, stope pogrešaka, nizvodna vremena i upotrebu resursa prije i nakon promjene. Niže prosječno vrijeme odgovora nije pobjeda ako se pogoršaju latencija repa, potrošnja memorije ili operativna složenost.

Najjači asinkroni PHP sustavi rijetko su najegzotičniji. Oni su jasni u pogledu granica ovisnosti, konzervativni s ponovnim pokušajima, disciplinirani s vremenskim ograničenjima i iskreni o tome koji rad pripada zahtjevu. Učinite čekanje konkurentnim tamo gdje je sigurno, premjestite trajni rad iz kritične putanje i neka ponašanje pri neuspjehu bude lakše razumjeti od sretne putanje. Tako pozadinske performanse postaju brze bez postajanja krhkima.