[PHP + MySQL] 100 geb. tegelijk online is 100 database verb.

[markg85]

sorry voor het inkorten van de topic naam.. het past gewoon niet

Maargoed wat is nu het probleem.. ik maak een script genaamd paFileDB Extreme Edition wat gebaseerd is op het script paFileDB. Ikzelf maar het script en test het, maar kan het nou ook weer niet met honderden gebruikers tegelijk testen omdat ik simpelweg niet zo`n site heb. er is vast wel een simulatie voor, maar dat hoeft op dit moment niet (vind ik).

Er zijn gebruikers van het script (of het script waarop het gebaseerd is) die wel van die extreem hoge gebruikers aantallen hebben en die komen het probleem tegen dat er gigantisch veel database verbidingen tegelijk open staan. Nu heb ik ergens in 1 van die server reviews van tweakers.net gelezen dat tweakers zelf maar een paar verbindingen tegelijk open heeft terwijl er toch soms veel meer dan 100 mensen tegelijk online zijn.. en toch kan ik de laatste nieuwsberichten gelijk op de hoofdpagina te zien... ik lijk niet te hoeven wachten op een cache die weer word aangevult.

Nu is mijn vraag.. hoe kan ik die verbindingen zo effectief mogelijk maken dat er nooit meer dan 5 (of iets dergelijks) tegelijk open zijn?

Of doet tweakers iets als dit:
Gebruiker 1 komt op de site, maakt automatisch een database verbinding en door middel van tig regels php wordt gecontroleerd of de cache maximaal 5 minuten voor hem al is ververst.. zo niet.. verversen!

Gebruikers 2 komt 1 minuut later en haalt dus eigenlijk gewoon een cache op

of werkt tweakers niet zo??

Wat hulp zou geweldig zijn
Thanx.

[Tys]

Begin eens met het controleren of paFileDB gebruik maakt van de mysql_pconnect functie.
Uit ervaring, dat scheelt al een hoop connecties aangezien ze lang nooit allemaal tegelijkertijd bezig zijn.

[Martijntj]

Ik gok dat Tweakers dmv CRON gewoon automatisch een file in elkaar zet; en dus niet wachten op gebruiker 1 (wat er uiteindelijk voor zorgt dat gebruiker 1 lang(er) moet wachte)

[GlowMouse]

Waarschijnlijk heeft Tweakers.net een crontab draaien dat elke x seconden de cache bijvult. Wat gebeurt er namelijk bij jouw idee: terwijl gebruiker1 de cache ververst, zal een gebruiker die ongeveer rond hetzelfde moment komt de cache ook bij proberen te werken. Daarnaast kost het bijwerken ook tijd, en daar wil je gebruiker1 niet op laten wachten.
Alleen de echt dynamische delen die per gebruiker verschillen hoef je dan nog maar te genereren. Als je usertabel in de database staat, zul je daar alsnog een databaseverbinding voor moeten openen. Zolang je een goede server hebt en je goede indices aanmaakt, moeten 100 gelijktijdige gebruikers makkelijk te verwerken zijn. Houdt er rekening mee dat een gebruiker misschien maar 3x per minuut op een link klikt, dus dan zit je met maar 5 databaseverbindingen per seconde. Dat is echt niets.

[crisp]

De meeste pagina's hier op tweakers worden volledig dynamisch gegenereerd. Er worden wel onderdelen gecached (de trackers bijvoorbeeld, of een static versie van de frontpage voor niet-ingelogde gebruikers) maar die gecachede versies worden ook allemaal in de database opgeslagen.
Voor elke hit wordt er dus sowieso een database connectie gemaakt en worden er bijna altijd wel meerdere queries uitgevoerd. Dat is geen probleem zolang je geen persistent connecties gebruikt en de connecties ook zo snel mogelijk weer vrijgegeven worden.

[markg85]

Thiaz schreef op zaterdag 06 januari 2007 @ 14:28:
Begin eens met het controleren of paFileDB gebruik maakt van de mysql_pconnect functie.
Uit ervaring, dat scheelt al een hoop connecties aangezien ze lang nooit allemaal tegelijkertijd bezig zijn.

het gebruikt standaard mysql_connect(), maar kan ook gebruik maken van mysql_pconnect()

crisp schreef op zaterdag 06 januari 2007 @ 14:43:
De meeste pagina's hier op tweakers worden volledig dynamisch gegenereerd. Er worden wel onderdelen gecached (de trackers bijvoorbeeld, of een static versie van de frontpage voor niet-ingelogde gebruikers) maar die gecachede versies worden ook allemaal in de database opgeslagen.
Voor elke hit wordt er dus sowieso een database connectie gemaakt en worden er bijna altijd wel meerdere queries uitgevoerd. Dat is geen probleem zolang je geen persistent connecties gebruikt en de connecties ook zo snel mogelijk weer vrijgegeven worden.

en jij zegt weer dat je dus juist geen mysql_pconnect() moet gebruiken?
dan komt bij mij vanzelf de vraag: wat ik get grote verschil tussen mysql_connect() en mysql_pconnect()? welke gebruik je waar en wanneer?

en op dit moment is er nog geen usertabel.. alles is dus (nog) publiekelijk toegankelijk... al moet ik wel zeggen dat ik wel een usertabel erin ga stoppen zodat de admins wat meer controle over hun database hebben en desnoods dat gebruikers in moeten loggen en anders gewoon niets zien. Op dit moment is er alleen een admin tabel.

Hoe het uiteindelijk gaat werken (of dat is het idee) is als een soort forum alleen dan geen treads, maar categorieen met daarin (links naar) bestanden.

[Verwijderd]

markg85 schreef op zaterdag 06 januari 2007 @ 15:26:

en jij zegt weer dat je dus juist geen mysql_pconnect() moet gebruiken?
dan komt bij mij vanzelf de vraag: wat ik get grote verschil tussen mysql_connect() en mysql_pconnect()? welke gebruik je waar en wanneer?

Artikel over persistent connections

Met de mysql_pconnect functie wordt geprobeerd overhead te beperken. Maar zoals je in dat artikel leest, is de overhead om the authenticaten niet zo groot. Daar staat tegenover dat er op de client meer resources gebruikt worden, waar je net zo goed wat aan de mysqld instellingen had kunnen doen om de boel beter te laten performen.

Mijn advies: zorg ervoor dat persistent connections niet worden toegelaten. Dat kan je in de php.ini opgeven. Je script zou gewoon moeten blijven werken.

Uiteraard heb je per gebruiker een database connection, maar dat heb je toch nodig. Maar die connections horen maar kort te duren. De client connect, doet wat hij moet doen, en disconnect weer. Als je dan nog 100 connecties tegelijkertijd hebt, moet je je afvragen of je tabellen, indexen en queries wel efficient zijn.

[ACM]

Ik weet niet precies hoe jij "een gebruiker is online" definieert, maar als dat iemand is die een webpagina zit te bekijken, dan moet je natuurlijk niet vergeten dat tijdens het lezen de verbinding met de webserver en dus ook van de webserver naar de databaseserver allang weer dicht zit.

Stel dat je webservers voor elke webpagina gemiddeld 0,25 seconden lang met de database communiceren. En stel dat je een gebruiker die "online is" gemiddeld genomen elke 30 seconden een link aanklikt. Als je dan kijkt naar een situatie met 600 gebruikers online, dan heb je dus in een minuut tijd 1200 pageviews die elk gemiddeld 1/4e seconde je database belasten. Dus 20 per seconde (1200/60) en aangezien elke connectie maar 1/4e seconde duurt heb je dan dus 5 connecties tegelijk open (met in totaal natuurlijk 20 connecties per seconde).

Op Tweakers.net is die gemiddelde belasting - meen ik - overigens meestal onder de 0,1 seconde. Dus met de 1443 pageviews die we volgens de titel de afgelopen minuut hadden is dat gemiddeld zo'n 2,4 connecties open tegen ruwweg 24 connecties per seconde.

[ACM]

't Nadeel van php/apache en pconnects is overigens dat voor elk apache-process er een verbinding open gehouden wordt, ook als dat process op dat moment met iets heel anders bezig is (plaatje serveren ofzo). En dat zorgt er natuurlijk voor dat je meer connecties tegelijk open hebt dan je in de praktijk nodig hebt.
Er is uiteraard wat overhead om connecties weer te openen, maar een ongebruikte connectie kost ook resources op de server. Dus dat is zeker niet altijd een voordeel. In ons geval zouden we met 5 webservers die ieder bijvoorbeeld ieder 40 apache-children open hebben bij pconnects rekening moeten houden met 40*5 = 200 continu open staande verbindingen... En ook al worden ze niet continu gebruikt, het heeft wel invloed op het geheugengebruik en de prestaties van de database.

[markg85]

dat is allemaal erg interessant volgens mij kan ik nu op dit moment dus het beste kijken waar me queries staan en hoe ze gedaan worden om iniedergeval die verbindingen weer gelijk te sluiten wanneer ze niet meer nodig zijn.. nu op dit moment wordt de verbinding gemaakt en aan het einde van de pagina weer afgesloten.. beter zal dus zijn om eerst alle data te fetchen die nodig is, dan de verbinding weer te sluiten en dan php erop los te laten..??

Ef hebben jullie een ander idee van hoe het eigenlijk zou moeten gaan?