[MySQL] Maximum connecties

Pagina: 1
Acties:

  • MrQcue
  • Registratie: Januari 2005
  • Laatst online: 13-01 08:55
Wij zitten met het volgende probleem. Voor meerdere drukbezochte sites hebben wij problemen met het registeren van custom statisische gegevens (tellers). Uiteindelijk moeten deze gegevens in een mysql database komen.

Het betreffen hier meerdere sites met enkele 10.000en tot 100.000en views per dag. Alles draait achter een loadbalancer op meerdere webservers die in verbinding staan met een NFS.

Tot op heden is er gekozen om tellers te plaatsen in text-files op de lokale webservers ivm performance. 'S nachts zouden de text-files ingelezen kunnen worden en in een mysql db worden verwerkt.

Het hele probleem met de mysql db is eigenlijk het aantal gelijktijdige verbindingen die worden gemaakt naar de mysql db. Het zou nl. mooi zijn als alles rechtstreeks in de database verwerkt zou kunnen worden.

Voor alle duidelijkheid: functies als mysql_pconnect gaan niet werken omdat deze alleen binnen het script werken. Wanneer een script meerdere keren wordt aangeroepen zal mysql_pconnect alleen maar meer overhead opleveren tijdens het maken van de (nieuwe :'( ) verbinding met de mysql db.

Op internet kan ik niet echt goeie oplossingen vinden voor bovenstaand probleem.

Iemand ervaring met dit probleem of een creative mind? >:)

  • flashin
  • Registratie: Augustus 2002
  • Laatst online: 17-12-2023
Gebruik je die database nergens anders voor? Want een paar 100.000 simpele inserts over 1 dag moet makkelijk kunnen.

mysql_pconnect() is wel een oplossing voor minder load, maar dan moet je je servertje ff goed configureren. http://nl3.php.net/mysql_pconnect

  • Janoz
  • Registratie: Oktober 2000
  • Laatst online: 11:06

Janoz

Moderator Devschuur®

!litemod

Met flashin.

Hebben jullie daadwerkelijk al performance problemen ondervonden? Het lijkt me namelijk heel onwaarschijnlijk dat een simpele update de connectie zo lang nodig heeft dat de hele boel in het honderd loopt. Sterker nog, ik vermoed dat jullie huidige oplossing voor meer performance issues en race problemen zorgt aangezien een dergelijke filesysteem oplossing waarschijnlijk iets met concurrency doet.

Ken Thompson's famous line from V6 UNIX is equaly applicable to this post:
'You are not expected to understand this'


  • MrQcue
  • Registratie: Januari 2005
  • Laatst online: 13-01 08:55
Het aantal insert's is in deze ook niet het probleem. Het is een dedicated master/slave mysql opstelling. Het probleem ligt hem aan het aantal gelijktijdige verbindingen naar de database. Voor iedere visitor wordt het script aangeroepen en dus een nieuwe connectie aangemaakt.

Op drukke momenten overstijgt het script het maximale aantal gelijktijdige connecties ('Too many connections') makkelijk. Uit een test bleek dat dit aantal (maximum connections) verhogen geen optie is.

  • LauPro
  • Registratie: Augustus 2001
  • Laatst online: 09:32

LauPro

Prof Mierenneuke®

Als het echt puur om de connecties gaat zou je 1 centrale stats-servers kunnen maken waar je via een socket de hits heen schrijft welke vervolgens 1 connectie met de DB heeft.

En anders zou ik het toch meer gaan zoeken in een vorm van caching.

Inkoopacties - HENK terug! - Megabit
It is a war here, so be a general!


  • Yo-han
  • Registratie: December 2001
  • Laatst online: 02-10-2025

Yo-han

nope.

Je zou eens kunnen kijken naar MySQL Connection pooling. Overigens zou het netjes sluiten van je connecties toch ook al wat ruimte voor je server moeten creeëren.

  • GX
  • Registratie: Augustus 2000
  • Laatst online: 14-05-2025

GX

Nee.

MrQcue schreef op woensdag 04 oktober 2006 @ 10:56:
Voor alle duidelijkheid: functies als mysql_pconnect gaan niet werken omdat deze alleen binnen het script werken. Wanneer een script meerdere keren wordt aangeroepen zal mysql_pconnect alleen maar meer overhead opleveren tijdens het maken van de (nieuwe :'( ) verbinding met de mysql db.
Second, the connection to the SQL server will not be closed when the execution of the script ends. Instead, the link will remain open for future use (mysql_close() will not close links established by mysql_pconnect()).
Dus, tenzij je PHP als CGI gebruikt is je stelling onjuist. Gebruik je PHP als CGI, dan zal ik als ik jou was eerst daar wat aan doen.

  • LauPro
  • Registratie: Augustus 2001
  • Laatst online: 09:32

LauPro

Prof Mierenneuke®

Volgens mij kan mysql_pconnect afhankelijk van je load-balancing opties in apache alsnog 40 connecties aanmaken als apache 40 threads maakt.

Echter met 1 centrale stats server kan je hele banale stats natuurlijk wel veel beter stroomlijnen. Als je stats per 5 minuten neemt kan die server eerst alle stats 5 minuten cachen in het geheugen en daarna committen naar de database.

Inkoopacties - HENK terug! - Megabit
It is a war here, so be a general!


  • B-Man
  • Registratie: Februari 2000
  • Niet online
Je zult inderdaad (zoals LauPro) zegt het aantal connecties moeten verminderen. Dit kun je ofwel in PHP zelf doen (middels een lokale textfile per apache process), alleen zit je dan met lokale concurrency issues (zoals janoz aangaf).

Je kunt het ook buiten PHP doen, door in java/php/.net een stukje software te schrijven dat uit binnenkomende verbinding een regel data leest, die x minuten lang cached, en dan in een batch commit naar de database.

Je zit met zo'n stukje software echter wel weer met wat andere zaken:
- SPOF, tenzij je het dubbel uitvoert (kan in principe makkelijk, er zit weinig/geen logica in de software)
- kun je zoiets programmeren? Ik zou zoiets doen middels select()/NIO in java, zodat je niet zit met een thread per connectie

  • LauPro
  • Registratie: Augustus 2001
  • Laatst online: 09:32

LauPro

Prof Mierenneuke®

Als je statistieken bij werkt aan het einde van een request heeft de client allang deze gegevens binnen en hoeft deze niet te wachten, stel dat het 1 seconde duurt om de stats te verwerken dan zou je heel veel threads in apache krijgen, maar geen last aan de client-kant.

Inkoopacties - HENK terug! - Megabit
It is a war here, so be a general!


  • MrQcue
  • Registratie: Januari 2005
  • Laatst online: 13-01 08:55
:X mja mysql_pconnect lijkt inderdaad toch wel een goeie optie. Toch eerst maar eens op php.net goed kijken.

We gaan dit testen.

  • B-Man
  • Registratie: Februari 2000
  • Niet online
LauPro schreef op woensdag 04 oktober 2006 @ 13:43:
Als je statistieken bij werkt aan het einde van een request heeft de client allang deze gegevens binnen en hoeft deze niet te wachten, stel dat het 1 seconde duurt om de stats te verwerken dan zou je heel veel threads in apache krijgen, maar geen last aan de client-kant.
Dat hangt er natuurlijk vanaf of PHP dan zijn output buffer al geleegd heeft. Als dat niet het geval is, dan moet iedere client op een druk moment alsnog wachten tot de stats zijn weggeschreven, zodat het script klaar is, en PHP zijn output naar de client schrijft. Hier is natuurlijk omheen te werken, maar het is standaard niet zo dat de client direct de output van je script binnenkrijgt.

  • LauPro
  • Registratie: Augustus 2001
  • Laatst online: 09:32

LauPro

Prof Mierenneuke®

Uiteraard na de flush :) .

[ Voor 8% gewijzigd door LauPro op 06-10-2006 13:29 ]

Inkoopacties - HENK terug! - Megabit
It is a war here, so be a general!


  • ACM
  • Registratie: Januari 2000
  • Niet online

ACM

Software Architect

Werkt hier

flashin schreef op woensdag 04 oktober 2006 @ 11:17:
mysql_pconnect() is wel een oplossing voor minder load, maar dan moet je je servertje ff goed configureren. http://nl3.php.net/mysql_pconnect
Met meerdere webservers die apache draaien is dat juist niet altijd de beste oplossing... zeker niet met de relatief lage overhead die MySQL voor het connecten heeft. Als we hier op Tweakers.net mysql_pconnect zouden gebruiken zouden we in het ergste geval 5x255 connecties naar beide databases open hebben... en op rustige momenten nog steeds 5x25-5x50
Nu we dat niet gebruiken is het op drukke momenten met 30-50 connecties al wel gedaan. En het moet wel heel druk zijn willen we richting de 100 gaan.

[ Voor 4% gewijzigd door ACM op 06-10-2006 13:54 ]

Pagina: 1