[PHP/mysql] mysqlfreeresult, closedb, etc. Doen of niet?

[kmf]

Al deze "nette" functies van php, om je database connectie netjes af te sluiten, de geheugen die werd gebruikt voor de resultaten te klaren, etc.

Is het nou wel of niet goed om deze consistent te gebruiken? De resultaten van een query wordt na de executie wel opgeruimd, dus zorgt zo'n functie dan niet voor extra overhead? Net zoals een DB-connectie afsluiten dus.

Ik heb gemerkt dat mijn applicaties nogal raar werken (onverwacht traag, soms weer snel) als ik deze functies gebruik.

[Grijze Vos]

Als je scripts hebt die echt veel data verstouwen. (Zeg > 8MB ofzo) dan is het vrestandig om je results te free'en, anders slurpt het geheel nogal asociaal veel geheugen. Voor de average site dus niet interessant. Gaat alleen maar executietijd in zitten, executietijd die je liever pas hebt na het outputten naar de client, niet ervoor.

[Skaah]

Het lijkt me een kleine moeite om zoiets op te nemen in je Database Abstraction Layer. Dan heb je er zelf geen werk van, maar werk je toch 'netjes'.
Die database verbinding zal toch een keer gesloten moeten worden, hou het dan zelf in de hand.

Weet je zeker dat het gedrag dat je omschrijft door deze functies komen?

[ixi]

Database verbinding hoef je niet te sluiten als je pconnect gebruikt. Je zou eens kunnen benchmarken om te zien hoeveel het scheelt.

Ik zelf ruim nooit iets op, tenzij het om heel veel data gaat (en dus de maxmemory van php.ini in zicht kan komen).

[vriesdude]

ik heb er nog nooit gebruik van gemaakt, maar ik heb een webapplicatie die soms enorm sloom is, ik weet dat deze echt enorm veel data uit de database haalt. ik ga zeker eens kijken of het de moeite waard is om mysqlfreeresult er op los te laten na de query.

[NMe]

Grijze Vos schreef op zaterdag 15 januari 2005 @ 10:56:
Als je scripts hebt die echt veel data verstouwen. (Zeg > 8MB ofzo) dan is het vrestandig om je results te free'en, anders slurpt het geheel nogal asociaal veel geheugen. Voor de average site dus niet interessant. Gaat alleen maar executietijd in zitten, executietijd die je liever pas hebt na het outputten naar de client, niet ervoor.

Deze discussie is al vaker gevoerd, maar ik haak er ook maar even op in. Ik vind het netter om alles wat je gebruikt ook daadwerkelijk af te sluiten op het moment dat je het niet meer nodig hebt. Nou is in PHP de garbage collection en dergelijke natuurlijk prima, en kun je er best vanuit gaan dat alles wat je gebruikt netjes wordt opgeruimd aan het eind van het script. Maar als je straks iets in een andere taal gaat programmeren, kun je niet zomaar uitgaan van een goeie garbage collector, en dan sta je mooi te kijken als je het opruimen/destroyen van variabelen en objecten vergeet.

Zelf zet ik dus in ieder geval code voor het sluiten van de database en het freeen van results onderaan mijn code, of, als dat interessant is, ergens in het midden om geheugen te besparen.

[Rhapsody]

Ik denk dat het gewoon moet.
Het is wel zo netjes, maakt beetje onderdeel uit het discipline in het programmeren. Gebruiken van de juiste prefixen, datatypen en zelf netjes opruimen.

Zo'n Garbage Collector is hartstikke leuk natuurlijk, maar je wordt er een beetje lui van op programmeergebied. Daarbij is het ook heel eenvoudig om dat op te nemen in je Database layer, zoals hierboven al aangegeven.

[Evilbee]

Tegenwoordig heb ik mysql.trace_mode aan staan. Hierdoor programeer je een stuk netter. En ik krijg altijd meldingen te zien als ik mysql_free_result niet gebruik. Dus ik doe het nu wel, ook al is het een hele simpel select query.

Maar of het ook tijdswinst oplevert heb ik nog nooit getest. Ik heb ik iedergeval nooit die verschijnselen die je noemt gehad.

[prototype]

Hmmm, antwoord op je vraag: ja, doen. Deze methods zijn er niet voor niets. Om er zomaar vanuit te gaan dat garbage collectors alles voor je oplossen volstaat simpelweg niet mijns inziens; inefficient programmeren. Maar sowiesow, dergelijke functies hardcoded aanroepen vind ik niet heel erg slim. Beter schrijf je een handler classe voor MySql database (en later ook nog evt voor andere soorten db's) en laat je het een bepaalde interface implementeren. Deze classe schrijf je dan dusdanig dat resultaten ook bevrijd worden na gebruik en alles netjes afgesloten wordt. Combineer dit geheel met een database factory en je hebt een flexibele structuur gecreeerd van waaruit objecten geinstantieerd worden op een niet hardcoded niveau. Maar goed, designpatterns is misschien een discussie opzich, 1 ding is iig zeker, je hoeft dan nooit meer te kijken naar freeresult/closedb etc.. dat doet je handler classe dan al voor je als het goed is.

[ Voor 3% gewijzigd door prototype op 16-01-2005 13:48 ]