Razumevanje problema dolgega anketiranja v PHP

Domov » Python » Razumevanje problema dolgega anketiranja v PHP

Če ste kdaj poskušali v klasično PHP aplikacijo vgraditi vedenje v »realnem času«, ste verjetno naleteli na dolgo anketiranje in njegove nenavadne težave z delovanjem. Kar se sliši kot preprost trik – ohraniti zahtevo HTTP odprto, dokler ni na voljo nekaj novega za poslati – nenadoma sproži nerodna vprašanja o blokiranih procesih PHP, pomnilniku strežnika, časovnih omejitvah in kako naj bi sploh obstajala možnost skaliranja preko peščice uporabnikov.

Ta vodnik se poglobljeno poglablja v problem dolgega anketiranja v PHP-ju, zakaj se obnaša tako, kot se, katera ozka grla so resnično pomembna in kaj lahko storite glede njih. Pregledali bomo, kako dolgo delujejo ankete, zakaj naivno sleep()Implementacija, ki temelji na .NET, je pogosto slabša od kratkega anketiranja, kako lahko pomagajo sodobne zanke dogodkov in spletni strežniki ter katere optimizacije so vredne truda. Med potjo bomo primerjali dolgo anketiranje z WebSockets in Server-Sent Events, se dotaknili varnosti in obravnavanja napak ter si ogledali, kdaj bi morali PHP opustiti v korist nečesa, kot je Node.js ali upravljane platforme v realnem času.

Kaj je dolgo anketiranje in kako dejansko deluje?

V svojem bistvu je dolgo anketiranje le HTTP, kjer strežnik namerno odloži odgovor, dokler nima kaj zanimivega za povedati. Namesto da bi odjemalec vsakih nekaj sekund spraševal strežnik »je že kaj novega?«, pošlje zahtevo, ki jo strežnik drži odprto, in odgovori šele, ko so novi podatki pripravljeni ali ko je dosežena časovna omejitev.

Tipičen dolg cikel zahteve/odgovora za anketiranje izgleda takole: Brskalnik (ali kateri koli odjemalec) pošlje zahtevo HTTP posebni končni točki, strežnik sprejme zahtevo, vendar ne pošlje takoj odgovora, povezava TCP pa ostane odprta, medtem ko strežnik čaka na nove dogodke ali podatke.

Če prispe kakšen dogodek – sporočilo v klepetu, obvestilo, posodobitev igre – strežnik takoj odgovori čakajočemu odjemalcu. Odjemalec obdela ta koristni tovor in, kar je ključno, takoj sproži novo zahtevo za dolgo anketiranje, tako da vedno (ali skoraj vedno) obstaja ena odprta povezava, ki čaka na naslednjo posodobitev.

Če se nekaj časa nič ne zgodi, strežnik po konfigurirani omejitvi sčasoma omeji zahtevo in odgovori s praznimi podatki ali s koristnim tovorom »brez posodobitve«. Odjemalec še vedno pošlje novo zahtevo, ko prejme ta odgovor o časovni omejitvi, s čimer ohrani dolgotrajno vedenje s ponavljajočimi se klici HTTP namesto z eno samo neskončno povezavo.

Čeprav ljudje govorijo o »trajni« dolgi anketni povezavi, gre tehnično za zanko dokaj dolgotrajnih zahtev HTTP in ne za en neskončen tok. Ta subtilna razlika je za PHP zelo pomembna, saj je vsaka od teh zahtev običajno vezana na en delovni proces ali nit PHP za celotno življenjsko dobo.

Dolgo anketiranje v primerjavi s kratkim anketiranjem v PHP

Kratko anketiranje je preprostejši, staromodni vzorec: odjemalec po določenem urniku zahteva od strežnika nove podatke, strežnik pa takoj odgovori. Morda boste zadeli /notifications vsakih 3-5 sekund hitro preverite bazo podatkov in pošljite dol vse novosti.

O tem pristopu je enostavno razmišljati, vendar je strašno potraten, saj večina anket ne vrne "nič novega". Z nenehnim tokom večinoma praznih odgovorov porabite procesor, poizvedbe v bazi podatkov in omrežne stroške, uporabnik pa lahko še vedno opazi zamude med dogodkom in naslednjo načrtovano anketo.

Dolgo anketiranje obrne model: manj zahtev HTTP, vendar vsaka preživi veliko dlje, medtem ko strežnik čaka na dogodek. Teoretično to zmanjša stroške HTTP in izboljša zaznano odzivnost, saj uporabniki prejmejo posodobitve takoj, ko se zgodijo, namesto da čakajo na naslednji interval anketiranja.

Težava v PHP-ju je v tem, da naivna dolga končna točka anketiranja preprosto blokira delavca za čas čakanja. Če držite povezavo odprto 300 sekund z uporabo zanke z sleep(), vežete PHP proces ali nit, ki bi sicer lahko v istem časovnem okviru postregla s številnimi hitrimi zahtevami za kratke ankete.

Ko primerjate oba pod obremenitvijo, lahko slabo implementirana končna točka z dolgim ​​​​polziranjem dejansko obdela veliko manj sočasnih odjemalcev kot kratka končna točka pollinga. Na primer, skupina PHP-FPM, ki lahko zlahka postreže s tisoči drobnih 5-sekundnih anket, se lahko ustavi, če vsak uporabnik za 300 sekund hkrati zasede enega delavca.

Zakaj je klasični vzorec dolgega anketiranja v PHP problematičen

Zelo pogost recept PHP za dolgo anketiranje izgleda približno takole: »povečaj max_execution_time, zaprite sejo in nato ponovite zanko z sleep() med preverjanjem novih podatkov«. Konceptualno je preprosto: preprečite prezgodnji iztek časovne omejitve PHP-ja, sprostite zaklepanje seje, da se lahko izvajajo druge zahteve istega uporabnika, nato pa v zanki do ~300 sekund preverjate nova sporočila.

Znotraj te zanke bi lahko vaša koda poizvedovanje v zbirki podatkov ali pa v vsaki iteraciji pregleda nekaj predpomnilnika v pomnilniku in se za sekundo ali dve ustavi z sleep(1) da se izognete udarcu po ozadju. Če najdete novo obvestilo, prekinete zanko, pošljete odgovor in končate skript; če dosežete časovno omejitev brez novih podatkov, pošljete nazaj prazno polje ali oznako »brez posodobitev«.

Na strani odjemalca, malo JavaScripta (običajno prek $.ajax() v jQueryju ali fetch() v navadnem JS) večkrat pokliče to končno točko. Ko brskalnik prejme kakršen koli odgovor (podatke ali prazno polje), počaka morda nekaj sekund in nato takoj pošlje še eno dolgo zahtevo za anketo, ki se dejansko izvaja v nedogled, dokler uporabnik ostane na strani.

Čeprav ta vzorec deluje za majhno uporabniško bazo, zelo hitro doseže strme omejitve, saj vsaka čakajoča zahteva porabi celoten PHP proces. Z nastavitvijo Apache prefork ali PHP-FPM vsak blokiran primerek skripte ves čas mirovanja uporablja RAM in vire, kar pomeni, da je lahko opaznih že 30-40 sočasnih odjemalcev, 100+ pa brez skrbnega nastavljanja postane nevarnih.

Še huje, zlahka je napačno razumeti, kaj sleep() klic dejansko počne. Z vidika operacijskega sistema vaša PHP nit med tem spanjem dobesedno ne počne ničesar produktivnega, vendar se še vedno šteje kot aktivna nit, ki je ni mogoče ponovno uporabiti za druge zahteve.

Niti, procesi in model spletnega strežnika

Da bi resnično razumeli problem dolgega anketiranja v PHP-ju, morate pogledati, kako vaš spletni strežnik upravlja povezave in delovne procese. Tradicionalni Apache prefork ustvari več procesov, od katerih vsak obravnava eno zahtevo naenkrat; drugi MPM-ji ali PHP-FPM uporabljajo skupine delavcev s podobnim vzorcem ena zahteva na delavca.

Ko vsak odjemalec z dolgim ​​anketiranjem zadrži zahtevo odprto nekaj minut, hitro izčrpate ta omejeni nabor PHP delavcev. Vsak od njih večinoma miruje, blokira pomnilnik in preprečuje nadaljnji promet, ko dosežete konfigurirani maksimum.

V primerjavi s sistemi, zgrajenimi okoli neblokirajočih V/I in zank dogodkov, lahko ena sama nit operacijskega sistema žonglira s tisoči sočasnih povezav, dokler je večina od njih nedejavnih. V tem svetu "nekaj" znotraj operacijskega sistema res čaka, vendar to ni zahteven proces v uporabniškem okolju na povezavo.

Nginx je dober primer na strani HTTP: uporablja dogodkovno vodeno arhitekturo za upravljanje ogromnega števila odprtih povezav z zelo malo porabe pomnilnika. Ko PHP priključite na Nginx prek FastCGI ali PHP-FPM, lahko Nginx ohranja povezave odjemalcev aktivne in zahteve posreduje določenemu naboru PHP delavcev, kar doda nekaj manevrskega prostora, vendar ne odpravi čarobno blokiranja PHP skriptov.

Zato je preprosta mantra »vsaka dolga anketa blokira nit« poenostavitev, a še vedno boleče natančna za številne klasične uvedbe PHP. Razen če uporabljate asinhrono izvajalno okolje ali drugačno arhitekturo, se tipična PHP skripta izvaja sinhrono in bo delavca zaposlovala, dokler bo delovala.

Je Node.js tukaj res poseben?

Node.js se pogosto navaja kot čarobna rešitev, ker privzeto uporablja enonitno zanko dogodkov in neblokirajoči V/I. Namesto da bi Node ustvaril nit za vsako povezavo, spremlja številne odprte vtičnice hkrati in dejansko delo opravi le, ko prispejo podatki ali se sproži dogodek.

Zaradi te arhitekturne izbire je veliko lažje podpirati ogromno število nedejavnih dolgih anket ali povezav WebSocket na skromni strojni opremi. Ko ne teče nobeno sporočilo, je zanka dogodkov Node še vedno aktivna, vendar komaj deluje, poraba RAM-a na povezavo pa je majhna v primerjavi s klasično nastavitvijo PHP delavec na zahtevo.

Vendar PHP ni popolnoma izključen iz te igre; ima tudi sodobne knjižnice zanke dogodkov, ki zagotavljajo podobno neblokirno delovanje. Projekti, kot so ReactPHP, Amp ali Revolt, vam ponujajo dogodekno vodeno izvajalno okolje znotraj PHP-ja, ki lahko upravlja vtičnice ali asinhrone naloge, ne da bi pri vsaki povezavi sprožil blokirajoči delavec.

V praksi pa večina starejših PHP aplikacij še vedno deluje na sinhronem modelu z Apachejem ali PHP-FPM in brez zanke dogodkov. Za te aplikacije je sloves »Node je boljši pri dolgem anketiranju« večinoma upravičen, saj bi morali znatno preoblikovati svoj PHP sklad, da bi dosegli primerljivo skalabilnost.

Kako dolgo traja anketiranje v primerjavi z WebSockets in SSE

Dolgo anketiranje je le eden od načinov za pošiljanje podatkov s strežnika na odjemalca; WebSockets in Server-Sent Events (SSE) so pogosto bolj primerni za sodobne aplikacije v realnem času. Vsaka tehnika ima svoje prednosti glede kompleksnosti, zmogljivosti in porabe virov.

WebSockets vzpostavijo pravi dvosmerni kanal med odjemalcem in strežnikom prek ene same nadgrajene TCP povezave. Ko je rokovanje nadgradnje končano, lahko obe strani pošiljata sporočila po želji, ne da bi pri tem ponavljali glave HTTP, kar je velika prednost za aplikacije za klepet, igre za več igralcev, nadzorne plošče in vse scenarije s pogostimi posodobitvami.

SSE pa ponuja enosmerni tok dogodkov od strežnika do odjemalca prek dolgotrajne povezave HTTP. Odlično se poda za obvestila, prenose v živo ali kateri koli primer, kjer mora samo strežnik poslati podatke, odjemalec pa le redko pošlje informacije nazaj, ki presegajo začetno zahtevo.

Dolgo anketiranje je nekje vmes: simulira pošiljanje strežnika s ponavljajočimi se zahtevami HTTP, tako da še vedno plačujete stroške povezave in glave vsakič. Prednost je, da deluje z navadno HTTP infrastrukturo in standardnimi brskalniki brez dodatnih protokolov ali posebne podpore za odjemalce.

Številne knjižnice za delo v realnem času, kot je Socket.IO, dejansko začnejo z dolgim ​​​​polliranjem in nato nadgradijo na WebSockets, kadar je to mogoče, pri čemer dolgo polliranje obravnavajo kot rezervno možnost in ne kot primarni mehanizem. To vam veliko pove o relativni učinkovitosti dolgega anketiranja v velikem obsegu.

Varnostni vidiki za končne točke z dolgim ​​anketiranjem

Čeprav se dolgo anketiranje zdi kot nizkonivojska vodovodna podrobnost, je vsaka končna točka dolgega anketiranja še vedno le površina HTTP API-ja, ki jo je treba ustrezno zavarovati. Prvi neizogiben korak je, da se storitev streže izključno prek HTTPS, da prometa med prenosom ni mogoče prestreči ali spremeniti.

Poleg varnosti prenosa potrebujete strogo preverjanje pristnosti in avtorizacijo za vse dolge zahteve za anketiranje. Ne glede na to, ali uporabljate sejne piškotke, JWT-je, žetone API-ja ali OAuth, mora strežnik preveriti, ali vsaka odprta povezava ustreza veljavnemu uporabniku in ali ima uporabnik dovoljenje za prejem zahtevanega toka podatkov.

Nekateri klasični varnostni pomisleki brskalnika, kot je CSRF, so morda manj pomembni, če se ne zanašate na implicitno preverjanje pristnosti na podlagi piškotkov iz standardnih obrazcev, vendar morate vseeno upoštevati svoj specifični kontekst. Če so vključeni piškotki ali če lahko končna točka sproži spremembe stanja, potem ostajajo pomembne zaščite proti CSRF (žetoni, piškotki istega spletnega mesta itd.).

Validacija vnosa je prav tako ključna za dolge ankete kot za kateri koli drug HTTP API. Parametri, kot so identifikatorji kanalov, uporabniški ID-ji, filtri ali časovni žigi, morajo biti na strežniku očiščeni in potrjeni, da se prepreči vbrizgavanje SQL, prečkanje poti ali logične napake, ki bi lahko povzročile uhajanje podatkov med uporabniki.

Dolgo anketiranje odpira vrata tudi scenarijem zavrnitve storitve, ker so povezave v PHP namerno dolgotrajne in relativno drage. Uveljaviti morate razumne omejitve hitrosti na IP ali na račun, omejiti število sočasnih povezav in uporabiti časovne omejitve povezav, da ohranite porabo virov pod nadzorom.

Neprekinjeno spremljanje, beleženje in redni varnostni pregledi so zadnja plast obrambe. Beleženje napak pri dolgem anketiranju, neuspehov pri preverjanju pristnosti in nenavadnih vzorcev povezav vam daje podatke, ki jih potrebujete za odkrivanje zlorab, regresij ali težav s konfiguracijo, preden se te poslabšajo v resničnem prometu.

Obravnavanje napak in odpornost pri dolgem anketiranju

Ker dolgo anketiranje zahteva številne dolgotrajne povezave, je robustno obravnavanje napak ključnega pomena za preprečevanje kaskadnih napak ali zataknjenih odjemalcev. Začnite tako, da za vsako zahtevo nastavite realističen časovni limit na strani strežnika, da manjkajoči dogodek ne bo povzročil, da bi povezave visele za vedno.

Ko je ta časovna omejitev dosežena brez novih podatkov, se mora strežnik odzvati z jasno in dobro definirano koristno obremenitvijo. To je lahko prazen seznam, specifična struktura JSON ali stanje HTTP 204, vendar mora biti predvidljivo, da lahko odjemalec loči »še ni podatkov« od dejanskih napak.

Pri resničnih težavah na strani strežnika – izpadih baze podatkov, notranjih izjemah, neveljavnih parametrih – je pomembno, da pošljete natančne kode stanja HTTP. Kode, kot so 500 (napaka strežnika), 404 (vir ni bil najden) ali 401/403 (težave z avtorizacijo), omogočajo odjemalcu, da se ustrezno odzove, namesto da slepo poskuša znova.

Na strani odjemalca je logika samodejnega ponovnega poskusa z eksponentnim umikom skoraj obvezna za dolga anketiranja. Če zahteva ne uspe ali se časovna omejitev nepričakovano izteče, naj odjemalec pred pošiljanjem naslednje zahteve malo počaka in v primeru ponavljajočih se napak podaljša čakalni čas, da se izogne ​​​​zastojem problematičnega zalednega sistema.

Preverjanje zdravja in upravljanje stanja povezave sta prav tako del dobre zasnove. Če odjemalec zazna izgubo omrežja ali ponavljajoče se napake strežnika, lahko preklopi na enostavnejši rezervni mehanizem, kot je kratko anketiranje, ali onemogoči funkcije v realnem času, hkrati pa uporabniku prikaže prijazno sporočilo.

Končno bi moralo biti vse to vedenje opazno: beleženje napak, časovnih omejitev in vzorcev ponovnih poskusov, nato pa uporaba teh dnevnikov in metrik za nastavitev časovnih omejitev, strategij umika in zmogljivosti infrastrukture. Dolgo anketiranje, ki tiho ne uspe, je eden najhitrejših načinov, da razjezite uporabnike in povzročite nediagnosticirane glavobole zaradi delovanja.

Strategije skalabilnosti, zmogljivosti in optimizacije

Naivno dolgo anketiranje v PHP se iz škatle ne skalira dobro, vendar obstaja veliko gumbov, ki jih lahko obrnete, preden ga popolnoma opustite. Cilj je zmanjšati stroške na povezavo in bolje izkoristiti vašo infrastrukturo.

Eden najbolj uporabnih trikov je združevanje odgovorov v pakete namesto pošiljanja enega sporočila na odgovor HTTP. Če v enem samem dolgem oknu anketiranja prispe več dogodkov, jih združite v en sam koristni tovor, da amortizirate režijske stroške HTTP in zmanjšate število ponovnih povezav.

Stiskanje lahko prav tako bistveno vpliva, zlasti pri podrobnih koristnih podatkih JSON. Omogočanje Gzip-a (ali podobnega) na ravni spletnega strežnika ali PHP-ja zmanjša velikost odgovorov, pospeši dostavo in zmanjša porabo pasovne širine, kar je opazno pri velikih količinah.

Predpomnjenja ne gre spregledati: namenska plast predpomnilnika lahko absorbira veliko ponavljajočega se dela, ki bi sicer obremenilo vašo bazo podatkov ali mikrostoritve. Če se na podobne tokove naroči veliko uporabnikov, lahko predpomnjeni posnetki ali izračunani agregati drastično skrajšajo čas obdelave na zahtevo.

Na strani povezave sta združevanje in ponovna uporaba pomembna predvsem za odvisnosti od zaledja, kot so baze podatkov ali zunanji API-ji. Če povezave z zbirko podatkov ostanejo odprte in ponovno uporabljene, namesto da se ponovno povežejo ob vsakem anketiranju, lahko to zmanjša zakasnitev in obremenitev procesorja, zlasti pri veliki sočasnosti.

Omejevanje hitrosti in dušenje imata dve vlogi: ščitita vašo infrastrukturo pred zlorabo in pomagata ohranjati predvidljivo delovanje pod obremenitvijo. Z omejevanjem pogostosti odpiranja dolgih anketnih povezav določenemu uporabniku ali IP-naslovu zmanjšate tveganje izčrpanosti virov in ustvarite prostor za pošteno uporabo.

Izravnavanje obremenitve med več aplikacijskimi strežniki je še en močan vzvod. Razporejanje dolgih zahtev za anketiranje po vozliščih preprečuje, da bi kateri koli posamezen računalnik postal vroča točka, zlasti v kombinaciji s lepljivimi sejami ali zunanjimi shrambami stanja za uporabniške naročnine.

Asinhrona obdelava in procesi v ozadju bi morali obravnavati vse, kar ni strogo gledano del zanke »čakaj na dogodek, pošlji dogodek«. Čakalne vrste sporočil, delavci opravil in porazdeljeni sistemi omogočajo, da vaša dolga končna točka anketiranja ostane tanka in odzivna, medtem ko se drugje opravlja veliko dela.

Ustrezne časovne omejitve za povezavo in skripte so zadnji varnostni ventili. Po razumnem času zaprite nedelujoče ali zagozdene povezave in jih ohranite max_execution_time v skladu z vašo logiko dolgega anketiranja in jasno določite, koliko časa lahko strežnik in odjemalec čakata.

Nasveti za implementacijo dolgega anketiranja, specifični za PHP

Pri implementaciji dolgega anketiranja v preprostem PHP-ju nekaj konfiguracijskih in kodnih podrobnosti močno vpliva na obnašanje in stabilnost. Eden velikih kliče session_write_close() čim prej v scenariju.

PHP-jev privzeti upravljalnik sej uporablja zaklepanje datotek, kar pomeni, da lahko zahteva, ki ohranja sejo odprto, blokira druge zahteve istega uporabnika. Zapiranje seje za pisanje izdaj, ki se zaklenejo, hkrati pa še vedno dovoljuje bralni dostop do podatkov seje, da se dodatne vzporedne zahteve ne postavijo v vrsto za dolgim ​​anketiranjem.

Običajno boste morali tudi zvišati ali preglasiti max_execution_time omejitev, ki omogoča izvajanje skriptov 60, 120 ali 300 sekund. Brez te prilagoditve lahko PHP ustavi skript, še preden se konča dolga zanka anketiranja, kar vodi do zmedenih napak na strani odjemalca ali delno dostavljenih odgovorov.

Znotraj zanke bodite zelo previdni glede tega, kako pogosto se obrnete na bazo podatkov ali druge zaledne sisteme. Tesna zanka, ki poizveduje po bazi podatkov vsakih 100 milisekund, bo vašo bazo podatkov stopila že pri zmerni obremenitvi; uvedite smiselna stanja mirovanja, predpomnilnike ali sprožilce tipa push, da bo sistem odziven.

Prav tako je vredno razmisliti o beleženju in metrikah znotraj te zanke. Spremljajte, kako pogosto izstopite zaradi časovnih omejitev v primerjavi z dejanskimi podatki, kako dolgo je povprečno čakanje in koliko sočasnih dolgih anket obdelate, nato pa te številke uporabite za načrtovanje zmogljivosti in optimizacijo kode.

Predvsem pa ne pozabite, da se vsaka blokirajoča PHP skripta preslika na delavca, zato je zmanjšanje zank, spanja in nepotrebnega dela bistvenega pomena, če želite podpirati več kot le peščico uporabnikov. Za interna orodja ali aplikacije z malo prometa je to morda povsem v redu; za karkoli večjega boste želeli robustnejšo arhitekturo.

Vzorci, knjižnice in alternative iz resničnega sveta

Mnogi razvijalci odkrijejo dolgo anketiranje prek majhnih predstavitev: PHP skript opazuje besedilno datoteko in ko to datoteko uredite, se sprememba takoj prikaže v brskalniku. To je odličen miselni model: preprosta koda, jasno vedenje in takojšnje povratne informacije.

V produkcijskem okolju ta trivialni primer hitro naleti na omejitve, o katerih smo razpravljali, vendar še vedno ponazarja osnovni protokol. Odjemalec JavaScript pošlje zahtevo AJAX, skript PHP pa se blokira, dokler se datoteka ne spremeni ali ne poteče časovna omejitev, nato pa se odzove in ponovi.

Za ekosisteme PHP boste našli nekaj ogrodja in vzorcev, ki poskušajo to narediti bolj obvladljivo. Laravel na primer spodbuja razvijalce k oddajanju dogodkov prek spletnih vtičnic (WebSockets) ali upravljanih storitev, čeprav lahko dolge poti anketiranja še vedno povežete ročno.

Zunaj PHP-ja obstajajo zreli ogrodji v skoraj vsakem jeziku, ki bodisi neposredno podpirajo dolgo anketiranje bodisi zagotavljajo lepše abstrakcije okoli komunikacije v realnem času. Node.js z Express.js ali Socket.IO, Python s Flask ali Django Channels, Java s Spring, Ruby on Rails in .NET z ASP.NET SignalR so vse priljubljene izbire.

Nekatere platforme vam v celoti skrijejo težavo s skaliranjem in povezavo. Upravljane storitve v realnem času – vključno s tistimi, ki se osredotočajo na sporočanje in prisotnost – ponujajo odjemalcem SDK-je, šifriranje, natančen nadzor dostopa in globalno infrastrukturo za obvladovanje milijonov sočasnih povezav, tako da vam ni treba znova izumljati kolesa.

V svetu PHP lahko pogosto dobite najboljše iz obeh svetov, če združite obstoječo logiko aplikacije s takšno storitvijo v realnem času. PHP ostaja odgovoren za poslovna pravila, vztrajnost in API-je, medtem ko zunanja platforma obravnava dolgotrajne povezave, razprševanje in dostavo v realnem času prek dolgega anketiranja, SSE ali spletnih vtičnic, kot je primerno.

Drugi ekosistemi te strategije v realnem času označujejo z imeni, kot so Comet, Reverse Ajax, HTTP Streaming, Pushlet ali AJAX long polling. V osnovi gre za različice iste ideje: pretvorbo protokola zahteve/odgovora v nekaj, kar deluje kot push.

Za razvijalce PHP, ki se spopadajo s težavami z dolgim ​​anketiranjem, je ključnega pomena, da iskreno ocenijo svoje potrebe po sočasnosti, svoje okolje gostovanja in koliko kompleksnosti so pripravljeni prevzeti. Včasih zadostuje preprosta blokirna zanka; drugič je bolje, da sprejmete knjižnico zanke dogodkov, prepustite push nalog namenski storitvi ali del svojega sklada preklopite na tehnologijo, zgrajeno za ogromno število odprtih povezav.

Ko vse te dele združite – mehaniko HTTP, model izvajanja PHP, arhitekturo strežnika, varnost, obravnavanje napak in prilagodljive vzorce oblikovanja – dolgo anketiranje preneha biti skrivnostni ubijalec zmogljivosti in postane le še eno orodje, ki ga lahko namerno uporabite, kjer je to smiselno.