[AJAX/SQL] Door Ajax enorm veel queries?

[Verwijderd]

Ik wil een real-time chat gaan maken dmv Ajax, PHP en MySQL. Daarvoor online op zoek gegaan naar voorbeelden en docs, aangezien ik geen ervaring heb met Ajax. Nu valt me op dat zo'n chat script werkt doordat er elke seconde met Ajax een query wordt uitgevoerd op de database.
Voorbeeld:

code:

<script>
function getMessages()
{
  new Ajax.Updater( 'chat', 'messages.php', {
    onSuccess: function() { window.setTimeout( getMessages, 1000 ); }
  } );
}
getMessages();
</script>

Bron: http://www.ibm.com/developerworks/library/x-ajaxxml8/

Als er dus elke seconde een query wordt uitgevoerd (minimaal 1) voor elke chattende gebruiker, dan kan het aantal queries wel heel snel oplopen. Ik denk niet dat mijn hostingpartij daar heel blij mee is.

Of zie ik iets ontzettend over het hoofd....?

[Niemand_Anders]

Kijk eens naar caching. Wij genereren simpelweg een HTML bestand zodra iemand iets toevoegt aan de chat. Het bestand wordt vanuit de database gegenereerd. De client herlaas elke 'X' seconden het bestand of zodra de bezoeker iets submit.

[Sjoerd]

Aangezien je alleen ophaalt wat je nog niet hebt lijkt het mij wel meevallen van resources maar kan er ook naast zitten natuurlijk, aangezien een query bij mij er ongeveer 0,0084s over doet om uitgevoerd te worden. zolang je geen 10 000 mensen hebt zal het allemaal best wel mee vallen denk ik zo

[Verwijderd]

Sjoerd schreef op dinsdag 29 januari 2008 @ 13:32:
Aangezien je alleen ophaalt wat je nog niet hebt lijkt het mij wel meevallen van resources maar kan er ook naast zitten natuurlijk, aangezien een query bij mij er ongeveer 0,0084s over doet om uitgevoerd te worden. zolang je geen 10 000 mensen hebt zal het allemaal best wel mee vallen denk ik zo

Mijn hostingpartij heeft zelfs sinds kort een maximum gesteld van 15.000 queries per uur. Ook al zijn het simpele queries, dan wordt het toch lastig.

[Ramon]

Neem dan gewoon de manier van Niemand_Anders, gewoon een html bestandje schrijven zodra iemand iets gezegd heeft. Ook niet erg mooi aangezien bestandstoegang ook niet zo snel is maar misschien wel sneller dan het via de database doen?

[Verwijderd]

Niemand_Anders schreef op dinsdag 29 januari 2008 @ 13:30:
Kijk eens naar caching. Wij genereren simpelweg een HTML bestand zodra iemand iets toevoegt aan de chat. Het bestand wordt vanuit de database gegenereerd. De client herlaas elke 'X' seconden het bestand of zodra de bezoeker iets submit.

Waarom wordt het bestand nog uit de database gegenereerd? Want hoe zorg je ervoor dat het bestand gevuld is met de data, zonder alsnog elke seconde een query op de database uit te voeren?

Kan je dan niet beter direct naar het bestand schrijven op het moment dat een gebruiker iets submit?

[Sjoerd]

Verwijderd schreef op dinsdag 29 januari 2008 @ 13:33:
[...]

Mijn hostingpartij heeft zelfs sinds kort een maximum gesteld van 15.000 queries per uur. Ook al zijn het simpele queries, dan wordt het toch lastig.

Ik denk dat het dan zoiezo lastig wordt...
Zoals hier onder gezegd hoe ga je een file genereren zonder steeds queries af te voeren?

15 000 is wel wat maar met 100 gebruikers zit je er zo door...

[RuudBurger]

Verwijderd schreef op dinsdag 29 januari 2008 @ 13:42:
[...]

Waarom wordt het bestand nog uit de database gegenereerd? Want hoe zorg je ervoor dat het bestand gevuld is met de data, zonder alsnog elke seconde een query op de database uit te voeren?

Kan je dan niet beter direct naar het bestand schrijven op het moment dat een gebruiker iets submit?

Direct naar een bestand schrijven lijkt mij nou niet de beste oplossing.
Dan krijg je problemen dat er meerdere gebruikers tegelijkertijd iets wegschrijven. Hier is in een database al aan gedacht en zullen die problemen niet voorkomen.
En je kan later nog wat anders met de data in het database doen als je dat zou willen.

De oplossing van Nieman_Anders lijkt mij in ieder geval een goede oplossing.

[ppx17]

Als je het snel wil oplossen kan je memcache gebruiken en daar de chatsessie in bijhouden, een html file kan ook maar die word in principe via het filesystem gedaan waardoor je hdd telkens bezig is. (Nou is een lamp combi heel goed met veel losse file's (ook caching in ram), dus maakt dat ook niet heel veel uit, maar toch.)

[Niemand_Anders]

ppx17 schreef op dinsdag 29 januari 2008 @ 13:59:
Als je het snel wil oplossen kan je memcache gebruiken en daar de chatsessie in bijhouden, een html file kan ook maar die word in principe via het filesystem gedaan waardoor je hdd telkens bezig is. (Nou is een lamp combi heel goed met veel losse file's (ook caching in ram), dus maakt dat ook niet heel veel uit, maar toch.)

Wij maken gebruik van een ramdisk (tmpfs) waarop het bestand wordt neergezet. Ook andere cache bestanden voor de website staan op de ramdisk. Onze ramdisk was 50MB.

Daarbij moet je je afvragen of het wel nodig is dat iedereen elke seconden opnieuw een refresh heeft. Waarom niet na elke 3 of 5 seconden een refresh.

Memcache doet eigenlijk precies hetzelfde als tmpfs. Alleen worden de chat 'bestanden' door apache als static afgehandeld, waardoor deze niet door de PHP parser hoeft. Op drukke websites kan dat voor een aardige vermindering van de load zorgen. Echter ik heb zojuist op de MemCached website gezien dat ze flink bezig zijn geweest in de afgelopen jaren, dus MemCache is zeker een aanrader.

[H004]

Wat voor chatscripts eigenlijk nodig is is ajax-push ipv ajax-pull. Dan wordt er alleen data verzonden als er ook nieuwe data is. Dit kan bv met Comet.

Alleen als je geen eigen server hebt wordt dat volgens mij wel lastig...

[curry684]

Verwijderd schreef op dinsdag 29 januari 2008 @ 13:33:
[...]

Mijn hostingpartij heeft zelfs sinds kort een maximum gesteld van 15.000 queries per uur. Ook al zijn het simpele queries, dan wordt het toch lastig.

Dat zijn er 4 per seconde.... wat een kuthoster

Ipv dat ie je nou op je falie geeft als je stomme queries uitvoert....

[Bosmonster]

Sillymidget schreef op dinsdag 29 januari 2008 @ 13:53:
[...]
Direct naar een bestand schrijven lijkt mij nou niet de beste oplossing.
Dan krijg je problemen dat er meerdere gebruikers tegelijkertijd iets wegschrijven. Hier is in een database al aan gedacht en zullen die problemen niet voorkomen.
En je kan later nog wat anders met de data in het database doen als je dat zou willen.

De oplossing van Nieman_Anders lijkt mij in ieder geval een goede oplossing.

Wel de chat bijhouden in de database en een bestand wegschrijven bij een nieuwe toevoeging en je hebt dat probleem niet.

Wat de TS ook aangeeft zit het probleem in het continu ophalen van de laatste chat-gegevens (wat dan vanaf file kan), niet bij het wegschrijven van die paar regels chat.

Voordeel is dat je wel de chat in de DB hebt voor terugzoeken en logging, maar dat je niet continu hoeft te query'en voor elke user elke seconde

[ Voor 8% gewijzigd door Bosmonster op 29-01-2008 17:47 ]

[rogierslag]

je kan ook elke seconde een query naar een database kunnen doen. Deze slaat het bestand op met alle data die je wilt hebben. Dat bestand wordt vervolgens opgehaald door de gebruikers.

Zo zit je netjes op 3600 queries/uur ongeacht je aantal gebruikers en je kan het posten netjes in de database zetten zoals je wilt

[BCC]

Als de SQL database gehit wordt en er is niets verandert, dan lepelt hij het resultaat toch gewoon op uit zijn query cache? Zoveel load levert dat nou ook niet ook. Memcached e.d. zijn wel echt noodgrepen imho. Die bemakkelijken niet echt het onderhoud.

[ Voor 9% gewijzigd door BCC op 29-01-2008 19:23 ]

[Voutloos]

curry684 schreef op dinsdag 29 januari 2008 @ 17:12:
[...]
Dat zijn er 4 per seconde.... wat een kuthoster
Ipv dat ie je nou op je falie geeft als je stomme queries uitvoert....

Precies. Op zich is cachen wel leuk, maar als je het moet doen om 1 zeer snelle query per hit te besparen mag je serieus gaan nadenken over een andere hoster.

Wtf echt. Monitor maar lekker slow queries (executietijd > x seconden, filesorts, copy to temp tables etc.) maar generaliseer niet elke query in zo'n suf kansloos regeltje.

Maar goed, ik vraag me ook af hoe erg het is als een chat applicatie slechts elke 2 a 3 seconde zou pollen... Verder kan je die timeout misschien ook wel iets langer maken als de gebruiker een tijdje niet actief is.

[ppx17]

BCC schreef op dinsdag 29 januari 2008 @ 19:23:
Als de SQL database gehit wordt en er is niets verandert, dan lepelt hij het resultaat toch gewoon op uit zijn query cache? Zoveel load levert dat nou ook niet ook. Memcached e.d. zijn wel echt noodgrepen imho. Die bemakkelijken niet echt het onderhoud.

De noodgreep is natuurlijk alleen nodig door de query limiet van zijn hoster, anders kan je het net zo goed met een ramdisk cache of een extra query af.

[g4wx3]

Moet je chatlog in een database staan?
Anders kun je toch gewoon steeds een lijn toevoegen aan een xml bstand?
(en alles na de 100ste wissen)

Zonier:
Zoals RogierSlag het voorstelt lijkt me ook de "beste" oplossing:

Refresh
AJAX => PHP => "last_update.xml"

post
AJAX => PHP => "to_update.xml"

Serverside:
PHP => "last_update.xml" properties creation_date < 1s =>NULL
PHP => "last_update.xml" properties creation_date > 1s => "to_update" => SQL => "lastupdate".


op deze manier werkte mijn webcam ook.
Omdat mijn lijntje nogal zwaar belast zou zijn door een webcam, en zoal traag upload, had ik een script gemaakt op de server die bij elke aanvraag aan de hand van de creationtime ging checken of het nodig was een nieuwe image op te halen, zoniet kreeg je de oude image, die stond gemirrord op de server. Op deze manier kon ik bewaken dat mijn webcam slechts door "mijn" server bekeken werd (om de 10 minuten, als er iemand online was), waardoor het bandbreede gebruik nooit boven een maximum uit kon gaan. (
*Dit zet me aan het denken dat ik eigenlijk eerst de image wil doorsturen, en nadien pas kijken of de image geupdate moet worden, zodat ie bij de volgende refresh geupdated word, en dat ie bij de aanvraag altijd meteen beantwoord kan worden. Is dat mogelijk, een php script laten lopen, nadat de gegevens zijn verstuurd, en de verbinding niet meer nodig is?

[ Voor 14% gewijzigd door g4wx3 op 29-01-2008 19:51 ]

[rogierslag]

aangezien de TS een 15000 queries per uur limiet heeft maakt het weinig uit of de cache wel of niet wordt aangesproken, daar trekt MySQL zich niets van aan. 1 query wordt gewoon geteld.

Als je iets doet als

PHP:

<?php
##############################
##### SCRIPT VARIABELEN ######
##############################

#tijd tussen veranderingen in seconden
$intChangeTime = 1;

#Locatie cache-bestand
$strCacheLocation = "webchat.html";


############################
# Hieronder niets wijzigen #
############################
# --------functies-------- #
############################

include('connections.php');     //je MySQL verbinding
include('functies.php');        //eventuele functies die je wilt toepassen, zoals je HTML markup
error_reporting(E_ALL);         //dat developt handig, ook ik maak fouten
ini_set('display_errors', 'on');    //dit ook ;). Net als het vorige verwijder je dit in je productieomgeving

if((time() - filemtime($strCacheLocation)) < $intChangeTime)
    {
    #Te vroeg opgevraagd dus serveren we het cache bestand
    $aContent = file($strCacheLocation);
    foreach($aContent as $display)
        {
        echo $dislay . "\r\n";
        }
    die();
    }

#Haal de gegevens uit de database
$aContent = array();

$strQuery = "SELECT gebruiker, tijd, bericht FROM webchat ORDER BY tijd DESC LIMIT 20"; //laatste 20 berichten uit database plukken
$rQuery = mysql_query($strQuery);
while($aQuery = mysql_fetch_array($rQuery))
    {
    //eerst maak je alles nog netjes op met HTML tags enzo
    $aContent[] = $aQuery[1] . ' | ' . $aQuery[0] . "\t| " . $aQuery[2];    //Query result in array flikkeren
    }

$fp = fopen($strCacheLocation,'w+');            //cache bestand aanroepen en leeggooien
foreach($aContent as $write)                //array-elementen wegschrijven in Cachebestand
    {
    $strDisplay = $write . "\r\n";          //zodat we dit echoen en niet weer een I/O activiteit plaatsen
    fwrite($fp,$write);             //wegschrijven inhoud
    }
fclose($fp);

echo $strDislay;
?>

Minimaal 0 queries per ur, maximaal 3600 door het tijdslimiet.

Voor toevoegen van posts voeg je gewoon een regel toe aan je tabel

[ Voor 3% gewijzigd door rogierslag op 29-01-2008 19:51 ]

[Voutloos]

g4wx3 schreef op dinsdag 29 januari 2008 @ 19:47:
Moet je chatlog in een database staan?
Anders kun je toch gewoon steeds een lijn toevoegen aan een xml bstand?

Erm, dan kan je net zo goed compleet filebased werken. Een file waar je alles aan toevoegt, een eentje waar je aan toevoegt, maar ook steeds een regel verwijdert. En wat heb je dan? Juist, een hoster waar je betaalt voor een db maar die amper/niet gebruikt. Kan je beter verhuizen naar eentje zonder db of zonder stomme regels.

rogierslag schreef op dinsdag 29 januari 2008 @ 19:50:
Minimaal 0 queries per ur, maximaal 3600 door het tijdslimiet.
Voor toevoegen van posts voeg je gewoon een regel toe aan je tabel

Nope. Je max is niet 3600. Je hebt maximaal 3600 selects, maar dat betekent dat je dan minimaal 3600 inserts hebt. Oftewel, 3 posts per seconde, of uberhaupt een paar andere eenvoudige queries en je site gaat alsnog op zwart.

offtopic:
En dit script kan een stuk korter door gewoon readfile() en file_put_contents() te gebruiken.

[ Voor 10% gewijzigd door Voutloos op 29-01-2008 20:05 ]

[g4wx3]

Dat heb je snel gescript rogierslag!
maar ik zou toch ook een cashe gebruiken voor de posts, want sommige spammers kennende gaat het aantal insert (=query) wel heel snel stijgen.
Dus moet je een soort post_buffer maken om alle posts in op te slaan, en tijdens je cashe update zet je dan je post_buffer in de database.Het is overbodig om dit eerder te doen, aangezien jou webchat.html niet eerder word geupdate.

En zoals aangehaald, het maakt de zaken onzinnig moeilijk, en je kunt het veel simpeler maken door 1 file te gebruiken. Sowiso moet je file-toegangsproblemen zien op te lossen, zoniet moet je zonder post-buffer werken, en kreeg je weer te veel queries..

Het word moelijlker dan ik dacht..

Oplossing is mischien ergens ander een database de gebruiken

Nope. Je max is niet 3600. Je hebt maximaal 3600 selects, maar dat betekent dat je dan minimaal 3600 inserts hebt. Oftewel, 3 posts per seconde, of uberhaupt een paar andere eenvoudige queries en je site gaat alsnog op zwart.

hoe kom je aan minimaal 3600 inserts? als er niemand iets post hoeft er toch geen insert te zijn??
en stal dat er 100 gebruikers zijn, die allen 1 post /seconde doen, dan kom je op 100 inserts/seconde
en dat gaat dus vrij snel oplopen, ofwel moet je een user limit gaan maken.

[ Voor 29% gewijzigd door g4wx3 op 29-01-2008 20:13 ]

[Voutloos]

g4wx3 schreef op dinsdag 29 januari 2008 @ 20:09:
hoe kom je aan minimaal 3600 inserts? als er niemand iets post hoeft er toch geen insert te zijn??

Klopt, maar rogierslag claimde een max aantal van 3600 q/h. Maar als je output cache bestand 3600x een nieuwe timestamp heeft, is deze niet alleen 3600x opnieuw aangemaakt (selects), maar is de db ook minstens 3600x gewijzigd. Maar goed, het cachen kan dus nog efficienter, maar je zou gek zijn als je je echt in onmogelijk bochten gaat wringen.

[ Voor 13% gewijzigd door Voutloos op 29-01-2008 20:29 ]

[rogierslag]

met file_put_contents had geen verschil gemaakt, de data komt namelijk als een array naar buiten gehuppeld. File_get_contents had wel tijd kunnen besparen

Over die insert had ik niet eens nagedacht. 15000 queries/uur lijkt veel, maar het valt nou tegen. 3600 selects (dan zit je al op een kwart van je capaciteit). Heb je 20 bezoekers en doet iedere pagina 15 selects, dan zit je heel snel aan dat limiet. 20 seconden per pagina is al 100 queries per minuut dan (15 * 20 / 3 = 100). Zodra er gezellig gechat wordt gaat dat ook problemen opleveren... Wissel dan van hoster, en snel!

[Ruudjah]

DIT BERICHT IS PREVENTIEF VERWIJDERD DOOR DE GEBRUIKER

[ Voor 96% gewijzigd door Ruudjah op 01-12-2009 22:23 ]

[FragFrog]

Ruudjah schreef op dinsdag 29 januari 2008 @ 21:25:
Waarom in vredesnaam een chatlog in een database opslaan? Lijkt mij de reinste waanzin. Je kan toch gewoon een object server-side in je geheugen stoppen? Om de zoveel tijd/data dan persisteren (opslaan). En voor het persisteren lijkt me een file de meest logische keuze.

Exactly, met memcache.

Let er wel op dat memcache werkt met een memcache deamon, die staat maar heel zelden geinstalleerd op normale hosters, en dat PHP's memcache functies zelf ook standaard niet meegecompiled zijn. Als je de server in eigen beheer hebt is dat zo verholpen (kwestie van DLL'tje downloaden onder windows, php.ini regeltje toevoegen en apache restart geven) maar de gemiddelde hoster zal denk ik niet zo snel dit voor je gaan regelen.

HTTP requests zijn stateless bij design, chatscripts zijn dat per definitie niet, dan krijg je dit soort fratsen. Als je een echt, drukbezocht chatscript wilt maken ben je in mijn opinie dan ook beter af met een java of activeX applicatie die wel zonder moeite een verbinding open kan houden (naar een IRC server bijvoorbeeld). Alternatief comet is in principe bedoelt om dit probleem op te lossen, maar ik heb nog maar weinig applicaties gezien die daar succesvol en goed gebruik van maken. Het zit er aan te komen, geef het nog een jaar of twee en het is wel ingeburgerd, maar voorlopig blijft het nog even aanknoeien vrees ik.

[ Voor 42% gewijzigd door FragFrog op 30-01-2008 00:20 ]

[Niemand_Anders]

Volgens mij hebben de meesten hier niet in de gaten hoeveel extra resources nodig zijn voor een PHP request ten opzicht van bijvoorbeeld een (statische) image. Op het moment dat char naar bestand wordt geschreven kan dit bestand (chat.html) door apache (lees: PHP engine hoeft niet geinitialiseerd te worden, hoeft geen geheugen te claimen, hoeft niet opnieuw configuratie te parsen).

Doe maar eens een performance test voor een test.html met alleen 'hello world' in de body en een test.php met <?PHP echo("<html><head><title>Test</title></head><body<h1>Hello world</h1></body></html>"; ?> test.html bevat uiteraard dezelfde html. Doe vervolgens 100.000 requests op test.html en daarna 100.000 requests op test.php.

Daarnaast hebben zowel Apache als IIS optimalisaties voor veel opgevraagde bestanden.

De database wordt gebruikt voor concurrency redenen (meerdere bezoekers welke op het zelfde moment een bijdrage aan de chat doen, locking issues, etc) en het systeem blijft werken op het moment dat de website geloadbalanced gaat worden.

De oplossing van rogier gaat wat mij betreft de goede kant op, alleen zou ik de lezers direct het webchat.html bestand laten ophalen. Hij is namelijk alleen anders als er een post wordt gedaan. De post ververst het bestand op de websevers en de bezoekers halen dit bestand op.

Het aantal (chat) database queries is dan gelijk aan het aantal posts * 2 (een insert + select). Je zou ook een stored procedure kunnen gebruiken welke de twee queries combineerd, waardoor je nog maar 1 'query' afvuurt op de database.

Als je al een tabel hebt kun je via de mysql query

SQL:

select avg(ChatLineID) from tblChat group by hour(timestamp)

inzicht krijgen hoeveel queries je per uur kunt verwachten.

[sig69]

Ik zou gewoon die hoster de welbekende vinger geven en een andere zoeken. Hosters te over zonder zo'n belachelijke limiet.

[FragFrog]

Niemand_Anders schreef op woensdag 30 januari 2008 @ 09:30:
Volgens mij hebben de meesten hier niet in de gaten hoeveel extra resources nodig zijn voor een PHP request ten opzicht van bijvoorbeeld een (statische) image.

Je bent nog niet met harde cijfers gekomen, heb je zelf wel in de gaten hoeveel het nu daadwerkelijk scheelt?

Een file is leuk, maar bij intensief gebruikte applicaties krijg je dan gegarandeert problemen met filelocks. Valt uiteindelijk vast wel omheen te komen, maar ik denk dat het prestatieverschil ten opzichte van memcache & PHP te verwaarlozen is, of in ieder geval beide zo laag dat het niet relevant is. Zeker aangezien PHP wel geladen moet worden, maar dat prima door je FS gecached kan worden terwijl een continue veranderent bestand dat niet kan.

Daar komt nog bij op dat je geen schrijfacties hoeft uit te voeren (je slaat de chat direct op in je servers werkgeheugen) en dat je geen SQL queries hoeft uit te voeren (hooguit af en toe een flush van je variabele als je het graag wilt loggen) zodat disk en SQL I/O netto veel minder is - wat toch doorgaans de grootste performance drains zijn.

Al met al verwacht ik niet dat het performanceverschil dan nog merkbaar is

[ Voor 29% gewijzigd door FragFrog op 30-01-2008 10:23 ]