[PHP] mysql_connect of mysql_pconnect *

Pagina: 1
Acties:

Onderwerpen


Acties:
  • 0 Henk 'm!

Verwijderd

Topicstarter
Ik heb hier een php script draaien met ongeveer 5 hits per seconden, momenteel gebruik ik mysql_connect() om naar de mysql database te connecten. De mysql db draait overigens niet op localhost maar op een andere server in het netwerk. Nu viel mijn oog op mysql_pconnect, deze maakt gebruik van persitente connecties naar de db, maw php hoeft niet steeds een nieuwe connectie met de db te maken. Alleen viel m'n oog op een aantal limieten:
- als m'n script crasht (bij 10 hits per sec zal er waarschijnlijk soms wel iets crashen zelfs al is de code goed) blijft de persistente connectie open.
- mysql heeft een maximale aantal connecties.

Hebben jullie een idee wat ik het beste kan doen?

Acties:
  • 0 Henk 'm!

  • curry684
  • Registratie: Juni 2000
  • Laatst online: 06-09 00:37

curry684

left part of the evil twins

bij 10 hits per sec zal er waarschijnlijk soms wel iets crashen zelfs al is de code goed
Als dit je vooraanname is zou ik toch maar eens je script nog goed gaan debuggen voordat je ermee live gaat.

Professionele website nodig?


Acties:
  • 0 Henk 'm!

Verwijderd

Topicstarter
curry684 schreef op 19 november 2003 @ 13:08:
[...]

Als dit je vooraanname is zou ik toch maar eens je script nog goed gaan debuggen voordat je ermee live gaat.
Het werkt al meer dan een jaar goed :) Ik nam aan dat door externe omstandigheden een php script onder zware load mogelijk een keer kan crashen of niet helemaal goed word opgeschoont. Ik neem aan dat je nooit kan zeggen "m'n script crasht nooit", je kunt uitgaan van de minst gunstigste situatie en dan kun je uitgaan dat je script kan crashen.

Acties:
  • 0 Henk 'm!

  • ripexx
  • Registratie: Juli 2002
  • Laatst online: 17-09 20:52

ripexx

bibs

Behalve dat PHP is MySQL ook een beperkende factor. Je zult MySQL ook moeten tunen. Een persistente connectie zou een hoop problemen moeten oplossen maar of daad werkelijk in elke situatie het geval is?

Waarom zou je script crashen? Je code klopt of het klopt niet. Alleen zul je merken dat bij meer hits de load zal gaan toenemen waardoor of je database(server) of je webserver het niet meer aan zal kunnen. Verder zijn er zat tools om je webapplicatie te stress testen zoals "ab van apache" en "Microsoft Web Application Stress Tool".

Let wel op de waarschuwing van PHP dat enige instelling van PHP en MySQL nodig zijn om het maximum aantal connectie naar je server toe niet overschreden worden. :)

buit is binnen sukkel


Acties:
  • 0 Henk 'm!

  • curry684
  • Registratie: Juni 2000
  • Laatst online: 06-09 00:37

curry684

left part of the evil twins

Verwijderd schreef op 19 november 2003 @ 13:32:
[...]
Het werkt al meer dan een jaar goed :) Ik nam aan dat door externe omstandigheden een php script onder zware load mogelijk een keer kan crashen of niet helemaal goed word opgeschoont. Ik neem aan dat je nooit kan zeggen "m'n script crasht nooit", je kunt uitgaan van de minst gunstigste situatie en dan kun je uitgaan dat je script kan crashen.
Een goed gedebugged en getest programma gaat nooit onderuit. En in een goed gedebugged en getest programma kun je garanderen dat de 'unexpected exception' nog geen 1 keer per jaar optreedt.

Professionele website nodig?


Acties:
  • 0 Henk 'm!

  • SinergyX
  • Registratie: November 2001
  • Laatst online: 11:01

SinergyX

____(>^^(>0o)>____

ik zelf heb een site/scripts die een 15-20 hits per seconde om zn oren krijgen, werk met de pconnect en de mysql wat getweaked tot 400 max verbindingen en een timeout van 5 secs (script verwerking is maximaal 2 secs). Blijkt het zeer goed te kunnen hebben, zit ik dus goed binnen de buffer (20 x 5 secs = 100 maximaal in 5 secs, uitloop 4 secs = 180 top)

Nog 1 keertje.. het is SinergyX, niet SynergyX
Im as excited to be here as a 42 gnome warlock who rolled on a green pair of cloth boots but was given a epic staff of uber awsome noob pwning by accident.


Acties:
  • 0 Henk 'm!

Verwijderd

Topicstarter
Daar was ik naar op het zoek KarreMania, praktijk voorbeelden. Dank je ripexx voor de suggesties, ik zal eens naar zo'n stresstool kijken. Ik doelde bij crashen meer op externe factoren zoals geheugen dat niet geheel goed is en andere gebruikers op de server die wat verkeerd doen. Maar inderdaad zoals curry684 zegt zullen problemen met de hardware e.d. zich niet vaak voordoen. Maar ik ga morgen aan de slag met de suggesties van KarreMania, die klinken erg logisch. ;)

Acties:
  • 0 Henk 'm!

  • ripexx
  • Registratie: Juli 2002
  • Laatst online: 17-09 20:52

ripexx

bibs

Behalve de optimalisaties van je wait_timeout en max_connections kan je ook andere variabelen aanpassen zodat je je server zodanig optimaliseerd, met name het memory gebruik van mysql is nogal te beinvloeden. (http://www.mysql.com/docu...on.html#Server_parameters)

Verder heeft mysql in het manual nog een aardig aantal tips staan die eventueel van pas kunnen komen. :) (http://www.mysql.com/docu...QL_Optimisation.html#Tips)

buit is binnen sukkel


Acties:
  • 0 Henk 'm!

  • Grijze Vos
  • Registratie: December 2002
  • Laatst online: 28-02 22:17
curry684 schreef op 19 november 2003 @ 15:35:
[...]

Een goed gedebugged en getest programma gaat nooit onderuit. En in een goed gedebugged en getest programma kun je garanderen dat de 'unexpected exception' nog geen 1 keer per jaar optreedt.
Dat vind ik een ontzettend gedurfde uitspraak. Ik neem aan dat je op de hoogte bent van het feit dat gemiddelde aantal bugs in gereleaste (en dus grondig geteste) software 3 op de 1000 regels code is.

Naar mijn mening is je programma pas foutloos als je dat wiskundig hebt bewezen, en ik denk niet dat de gemiddelde programmeur daar tijd in gaat steken, doe ik zelf ook niet, behalve voor school dan..

Op zoek naar een nieuwe collega, .NET webdev, voornamelijk productontwikkeling. DM voor meer info

Pagina: 1