Počet požadavků na free účet wz.cz

Dobrý den,
na své doméně chci spustit chat aplikaci, kterou jsem si sám napsal. Chci, aby se chat automaticky aktualizoval na pozadí stránky.

Můj dotaz zní: v jakém intervalu je vhodné dotazovat se serveru na nové příspěvky, tzn. jestli není obnova stránky každou sekundu za předpokladu asi 10 uživatelů moc velký nápor na server (Každou sekundu deset požadavků na jeden soubor).

Snad jsem to ze sebe vymáčknul srozumitelně.

Jedna sekunda je hodně velký nápor.

Nejde ani tak o zátěž serveru, i když zde hodně záleží, jak velké zdroje vyžaduje chat. Pokud to jede přes MySQL databázi, tak ta zátěž zde bude brutální. Zde by nepomohlo ani 10 sekund. MySQL zde málokdy jede dost rychle. A to ještě nemluvím o limitu na počet SQL dotazů. Jakmile dojde k překročení limitu, tak chat bude nefunkční.
Pokud to jde přes soubor, tak záleží, jak je to zabezpečené. Pokud to není zabezpečené, tak sekunda udělá z chatu pokec do prázdna. Pokud je to zabezpečené, tak je riziko zdržování, než jiný požadavek k souboru může přistupovat.

Problém je spíše jinde, a to síťová zátěž. Jedna sekunda je pro průměrné nebo podprůměrné připojení extrém. Prohlížeč i síť by nedokázaly za sekundu všechno zpracovat. Pokud k tomu dojde, tak se to celé zahltí a chat na straně uživatele zblbne.

Minimem je dle mě 10 sekund. Ale zde na WZ nelze zaručit bezproblémový chod i na této hodnotě.

Chat není zabezpečený, využití plánujeme jako rychlou komunikaci o hodinách na školních počítačích. Obnova probíhá načítáním souboru refresh.txt, kde je čas posledního příspěvku vygenerovaný v php (třeba 1357947435).

Refresh teda nastavím na 10 sekund, v pondělí udělám zátěžový test a pak to případně upravím.

Děkuji za rychlou odpověď

Zabezpečením chtěl Tomík nejspíš zmínit zamykání souborů. Pokud ukládáš zprávy z chatu do souboru a patřičně jej nezamykáš, přístupy se poperou mnohem dříve, než při 10ti uživatelích současně. Řešení přes soubory je ale obecně nevhodné; téměř ideální volbout tak zůstává SQLite ;)

Ad Tomík, část 2) Síťovou zátěž lze jednoduše ovlivnit na straně uživatele javascriptem; dokud předchozí požadavek na aktualizaci obsahu chatu neskončí, nebude se vytvářet nový. Jak prosté, milý Watsone.

Na závěr jeden postřeh.. předpokládejme, že přečtení jednoho nového příspěvku v chatu zabere 5 vteřin a s každou aktualizací přijde 1 až 2 nové příspěvky. Než člověk napíše odpověď na takový příspěvek, ztratí dalších 20 vteřin. Jedna "iterace" tak v podstatě zabere půl minuty; nezdá se v tomto kontextu aktualizace s každou vteřinou jako zbytečná.. ;)

Ad Freeze, část 2) No záleží jakou techniku použije. Pokud se jedná o obyčejný refresh, tak z toho zblbne prohlížeč skoro neustálým sekundovým načítáním stránky. Mohlo by klidně dojít, že po celou dobu bude mít bílou obrazovku, pač než to prohlížeč stihne stáhnout, rozparsovat a zobrazit, tak už je tu další obnova ;)
Pokud by na to šel formou ajaxu, tak tady je problém v ono prvním písmenku - asynchronní. Kdyby použil setInterval bez ošetření, tak je jedno, zda ajaxový požadavek skončil nebo ne. Každým intervalem se vytvoří nový požadavek bez ohledu na předchozí stav. Samozřejmě se to dá ošetřit, ale musel by vědět jak.
Vím své. Jsem svého času dělal hromadný mailing o stovek ne-li tisícovek emailů formou ajaxu. Zobrazím stránku se seznamem emailů k odeslání a po stisku tlačítka se na pozadí provádělo odesílání po jednom. Podmínkou však bylo nezatěžovat zbytečně server a umožnit přerušení nebo pozastavení odesílání. Klasickým ajaxovým kódem by to nefungovalo (respektive fungovalo, ale časem by to bylo mimo kontrolu). K tomu je potřeba připojit i režii. A bez dobré znalosti javascriptu by to bylo složité.