ugrás a tartalomhoz

Ajax long polling - szerver oldalról nézve

smart · 2011. Május. 4. (Sze), 10.10
Sziasztok, "azonnali" reakciót szeretnék a kliens oldalon elérni. Erre a Ajax long polling megoldást tökéletesnek tűnik. A kliens oldali elkészítéssel semmi gond sincsen.

Ám a szerver oldalon már bajba vagyok. Mit csinál a szerver eközben?

Ha egy adatbázistáblában megváltozik az egyik érték, vagy új rekord kerül be a táblába, akkor arról ugye csak úgy értesülhetek, ha néhány másodpercenként kiadok egy új lekérdező query-t az adatbázisszerver felé? Néhány ilyen és nem fog meghalni a szerver?

Hülye kérdés: ilyen long polling PHP és a DB között nincsen? :)

Vagy milyen megoldással lehet elérni, hogy a néhány perces reakció időt csökkentsem ezzel a long polling technikával, úgy hogy közben a szervert se öljem meg? :)

A válaszokat előre is köszönöm!
 
1

Ha egy adatbázistáblában

kuka · 2011. Május. 4. (Sze), 10.49
Ha egy adatbázistáblában megváltozik az egyik érték, vagy új rekord kerül be a táblába, akkor arról ugye csak úgy értesülhetek, ha néhány másodpercenként kiadok egy új lekérdező query-t az adatbázisszerver felé?
Attól függ mit kérdezel le. Ha triggert kötsz a táblára amelyben a friss adatok kell megjelenjenek, abból pedig egy kisebb táblába feljegyzed az utolsó változás adatait, akkor a PHP szkript a kis táblából kiderítheti, hogy mikor szükséges a nagy és fárasztó lekérdezést futtatni.
Vagy milyen megoldással lehet elérni, hogy a néhány perces reakció időt csökkentsem ezzel a long polling technikával, úgy hogy közben a szervert se öljem meg? :)
Nem említetted milyen adatbázist használsz. PostgreSQL esetén a listen használatával elkerülhető a fölösleges kérdezgetés. Sajnos PHP-ból nem tudom hogyan lehetne használni.
2

eseményvezérelve?

zzrek · 2011. Május. 4. (Sze), 11.53
Valami megváltoztatja az adatokat az adatbázisban. Ezt egy esemény váltja ki (amit PHPben kezelsz le), ezzel egy időben odaszólhatsz a várakozó algoritmusodnak. A jelzés mehet egy kisebb buffertáblában, vagy jelzőfájlban is, de talán máshogy is lehet (engem is érdekelne, hogy van-e más módszer odaszólni egy futásban lévő PHP szkriptnek)
3

Prezisztens réteg

Poetro · 2011. Május. 4. (Sze), 12.03
Az alkalmazásodban szükség van egy prezisztens rétegre, ami gyorsabb, és terhelhetőbb, mint egy átlagos adatbázis. Ez legjobb, ha valami memória alapú tároló, mint például memcached, Redis, APC cache stb. Ezt azon a szálon írod, ahol a változás történt, és ekkor a long pollingot kezelő szálon csak ezt a gyors, memória alapú alkalmazást kell kérdezgetni, hogy történt-e változás. Ha történt változás, akkor már a változásokat lekérheted adatbázisból is, de persze még jobb, ha már eleve ez a köztes réteg visszaadja a változásokat.

Egyébként a PHP nem igazán alkalmas long polling-ra, mivel rengeteg memóriát eszik. Képzeld el, hogy egy PHP szál mondjuk fogyaszt 10Mb memóriát, és a gépben van 1Gb. Ekkor összesen egyszerre 100 long polling tud futni, és még nem szóltunk arról, hogy magát a weboldalt is ki kellene szolgálni. Ilyen feladatokra sokkal jobb egy folyamatosan futó alkalmazás, ami csak a long pollingot kezeli, például Java-ban, vagy Node.js alatt JavaScript-ben megírva.
4

Re: Prezisztens réteg

smart · 2011. Május. 4. (Sze), 17.19
Köszönöm a választ! (a többiekét is)

Valószínűleg utána megyek a memcached-nek. Sajnos még nem foglalkoztam ezzel, úgy tűnik, hogy itt az ideje! :)

A PHP lecserélése jelenleg esélytelen vállalkozás lenne, pedig az általad leírt memória gondok nagyon elképzelhetőnek tűnik... kicsit elbizonytalanítottál. :(
5

Socket

janoszen · 2011. Május. 4. (Sze), 18.22
PHP-val is lehet esemény vezérlést csinálni. Nemrég írtam egy olyan alkalmazást, ami egy Syslog-NG végén csücsülő PHP-re csatlakozik Unix socketen keresztül. Persze az ilyesmi nem lehetséges / ajánlott osztott tárhely esetén, mert a szolgáltató már csak a slot/memória foglalásért is ki fog rakni. Ha részletesebben érdekel a téma, írok róla cikket.