AJAX Chat - Koliko zahteva je previše zahteva?

[Ilija Studen]

Upravo završavamo Chat modul za novi activeCollab. U pitanju je manje više klasičan AJAX chat gde client strana šalje zahteve i pita server da li ima nešto novo. Ako server ćuti (prazan odgovor) nema ništa novo, ali server takođe može da pošalje niz komandi kojima se osvežavaju poruke, lista ljudi u sobi, fajlovi itd.

Fajl koji client strana pinguje je tako napravljen da se izvršava jako brzo - ne učtavaju se nikakve biblioteke i slične gluposti - čista konekcija na bazu, par jednostavnih upita i šibaj. Na mojoj dev mašini se zahtev izvšava za 9 - 25ms što je kontam OK. Nismo još probali na nekom hostu.

Ono što mene zanima je koja učestalost slanja zahteva je najoptimalnija (trenutno smo setovali 1 zahtev na svaki sekund po korisniku)? Jeste imali iskustva sa sličnim stvarima? Kako hostovi reaguju na takve appove?

I slična pitanja. Dakle - pretresanje koncepta uzduž i popreko.

PS: Razlog zašto Ajax chat je zato što jedostavno radi. Nema prčkanja i petljanja, uvrnutih sistemskih zahteva i sličnih gluposti - uploaduješ i gruvaj.

[Gruja]

A koliko ce korisnika tu biti istovremeno? Od toga sve zavisi. Svaki od njih pikne bazu svake sekunde. AKo ih je 10-tak, nije mnogo strasno, ali za vise treba testirati.
Jedna varijanta je da se prebacuje stvari iz baze u memoriju.
Druga varijanta je da predjes na push - ukratko ne salje klijent novi request svakih sekund, vec posalje samo jedan request, a server mu malo po malo vraca podatke ne zatvarajuci konekciju.

Najlakse je ako zakljucis da ti ni ne treba dodatno zezanje, ipak ne pravis novi ICQ vec ce tu samo da se vrti par korisnika koji su trenutno u chatu. Ili je mozda zamisljeno da ceo dan drze otvorenu tu stranu?

[Ilija Studen]

Jeste izmišljanje rupe u saksiji, ali za app kao što je activeCollab Chat modul stvarno vredi i vremena i truda i živaca.

Koliko sam ja razumeo, push zahteva uvek otovrenu HTTP konekciju i nije baš najjednostavniji za podešavanje.

[LiquidBrain]

Verovatno bi trebalo da drzish sve to u memoriji, i kada predje odredjeni broj linija ti to lepo upishesh u bazu... To je sto se brzine tice, inace manje od dve sekunde je preterivanje, tako da stavi da pravi request na svake dve sekunde. Potpuno je nepotrebno ceshce... A i verujem da sto se tice samog broja korisnika necesh imati nesto mnogo aktivnih na chatu nikada... ipak nije to javni IRC server...

[caboom]

mozda nije lose da pogledas comet & friends, mada guglanje i nije dalo neke preterano ohrabrujuce rezultate ako zelis da se drzis samo php-a:

http://ajaxian.com/archives/new-chat-prototype-using-comet-and-prototype

[ivanhoe]

nema recepta za ovo, moras da uzmes i da izmeris:

a) koliko zahteva u sekundi moze server da podnese, a da se ne obore bitno perfomanse ostatka sajta/ova. Na osnovu ovog podatka i prosecnog broja zahteva na serveru u peak time-u videces koliko imas lufta za dodatni saobracaj.

b) kakav je subjektivni utisak kad se chatuje sa raznim podesavanjima (0.5s, 1s, 2...). Nadjes neki maximum koji ne stvara utisak prevelikog laga kad pokusavas sa nekim da pricas preko neta (iz nekog mog ircerskog iskustva do 2 sekunde, preko toga je mucenje).

I spremi se na to da ces morati da fine-tunujes ove parametre tokom rada, vec prema feedbacku koji dobijes i realnom opterecenju servera.

Obavezno ugradi opciju da chat ne prihvata nove konekcije ako je ispunjen neki uslov (max. broj konekcija, server load poraste ili nesto trece sto smislis...)

[noviKorisnik]

Možeš i da koristiš produžavanje intervala u slučaju neaktivnosti. Odrediš donju i gornju granicu (recimo od jedne do 64 sekunde), postaviš na donju i dupliraš do prve aktivnosti ili do gornje granice... Prototype ima PeriodicalUpdater (http://www.prototypejs.org/api/ajax/periodicalupdater) koji radi slično (mada ne vidim gornju granicu, a čini mi se nezgodno ostaviti je otvorenom).

[chux]

prijatelj me danas uputio na ovaj chat visubox, pa overite, sigurno će te ga već negde ubaciti kada klijent bude tražio chat.

http://www.visubox.com/v05/dblog/

[cvele]

Skoro sam radio nesto slicno tome, odnosno periodicne ajax pozive.
Naime u projektu postoji dosta callbackova koji moraju biti verifikovani a za verifikaciju se moze cekati i po nekoliko min (u teoriji i po nekoliko sati). Radio sam periodicne pozive da bih proverio da li je neki od tih poziva vratio nekakvu poruku i to prikazao korisniku.

Timer sam setovao na 2,5sec i to mi se cini kao nesto optimalno mada ne savrseno.
Razloge za zabrinutost u tvom kao ni u mom slucaju ja ne bih trazio u servereskoj strani vec na klijentskoj. Kada sve zavrsis, odredis interval itd Pokusaj da pola sata ili sat vremena koristis browser i surfujes sa periodicnim updejterom otvorenim u jednom od tabova van fokusa. Ono sto se desi jeste da browser postaje nezamislivo trom, kolicina utrosene memorije skace exponencijalno. Ovo pricam za FF, Safari kao i IE.

Kada god sam timer povecavao za 500ms vreme do ovakvog ponasanja browsera je postajalo duze ali se opet dogadjalo. Tek na setovanih 4sec simptomi su nestali... ipak 4sec je previse za ovakve potrebe.

To je moje licno iskustvo, nadam se da ce ti kolko tolko pomoci.

[Ilija Studen]

Da, u pravu si skroz. Imao sam dosta problema sa FF-om i tromošću dok smo radili na Chat modulu (tj. dok mi je non-stop bio otvoren).

Da li je još neko imao slična iskustva?

[kodi]

takodje, neki real time grafik sam radio ovde na poslu pre godinu dve, znao je da napumpa memoriju samo tako...
u medjuvremenu je prestala da postoji potreba za tako nesto, mada i dok je radio koristio se samo da na par minuta pogledas nesto.

medjutim meebo moze da mi bude otvoren po ceo dan i ne primecujem neko vece usporenje? jel oni rade on event ili putem periodicnih upita?

[cvele]

Samo jos za prototype periodicalUpdater.

Veoma je nezahvalan za kroiscenje u ovakvim situacijama. Razlog je nedostatak mogucnosti za clearovanje timeouta. Veoma je prosta fja u sustini tako da ako ti treba malo bolje optimizovana varijanta iste fje slobodno posalji pm.

Btw
u sledecoj verziji prototype ce biti izmenjena ova fja.