login  Naam:   Wachtwoord: 
Registreer je!
 Forum

mysql_unbuffered_query

Offline Ultimatum - 25/04/2007 06:44
Avatar van UltimatumPHP expert Omdat mij werd veteld dat de site waarin werk bij sommige heel traag is ben ik mij even gaan verdiepen in het zo efficient schrijven van queries. 1 van de dingen die ik via php.net tegen kwam is mysql_unbuffered_query. Deze buffert de resultaten niet zodat het sneller gaat.

Nu was de vraag, kan dit geeen kwaad als ik mysql_unbuffered_query gebruik ipv myql_query?

En op php.net staat dit
Citaat:
Aan de ene kant spaart dit een behoorlijke hoeveelheid geheugen met SQL queries die grote resultaat sets opleveren. Aan de andere kant kun je beginnen met werken met de resultaten set onmiddellijk nadat de eerste rij is opgehaald: je hoeft niet te wachten tot de volledige SQL query is uitgevoerd.


Wat bedoelen ze daarmee? Want als je normaal bijvoorbeeld een while hebt dan gaat hij ze toch ook 1 voor 1 langs zonder dat de query al klaar is? Zou iemand anders even een voorbeeld kunnen geven?

11 antwoorden

Gesponsorde links
Offline ArndJan - 25/04/2007 09:36
Avatar van ArndJan PHP interesse Als je minder dataverkeer wilt kan je met changing werken. Dit gewoon dynamisch .html pagina's aanmaakt. Zo heb je minder dataverkeer naar de server, werkt erg goed 

Maar over je mysql_unbuffered_query... lijkt me alleen voor niet altijd nodig alleen bij erg grote query's.
Offline Ultimatum - 25/04/2007 10:23
Avatar van Ultimatum PHP expert Wat bedoel je met changing? En de site is zo goed als klaar dus het is niet haalbaar om alles te herdoen. Ik wil gewoon de snelheid opkrikken met de code die ik nu heb 
Offline Gerard - 25/04/2007 11:26
Avatar van Gerard Ouwe rakker
Citaat:
Omdat mij werd veteld dat de site waarin werk bij sommige heel traag is ben ik mij even gaan verdiepen in het zo efficient schrijven van queries. 1 van de dingen die ik via php.net tegen kwam is mysql_unbuffered_query. Deze buffert de resultaten niet zodat het sneller gaat.
Hou je er wel rekening mee dat het niet mogelijk is om PHP.net: mysql_num_rows op te vragen van een unbuffered query omdat je nog niet weet hoeveel rijen er in de resultset zitten. Dit kan dus gevolgen hebben voor je applicatie.

Citaat:
Wat bedoelen ze daarmee? Want als je normaal bijvoorbeeld een while hebt dan gaat hij ze toch ook 1 voor 1 langs zonder dat de query al klaar is? Zou iemand anders even een voorbeeld kunnen geven?
Hij doet precies hetzelfde, alleen nu krijg je -wanneer hij een result heeft- deze al compleet terug in plaats van dat de hele resultset wordt verzamelt en deze in 1 keer wordt returned.

Citaat:
Omdat mij werd veteld dat de site waarin werk bij sommige heel traag is ben ik mij even gaan verdiepen in het zo efficient schrijven van queries.
Hoe kan een site bij sommige mensen heel traag zijn. Is het niet traag bij anderen dan? Welke pagina's zijn traag of is het altijd? Hoeveel queries voer je uit? Vraag je niet onnodig veel dingen op (SELECT *)? Zijn je JOINS correct? Maak je gebruik van gzip compression? Maak je overbodig gebruik van lussen in je site waar je dit ook stack based kan doen? Maak je gebruik van de constructie "for ($i=0;$i<count($iets);$i++"?

Er zijn 1001 methoden om je site sneller te maken....
Offline Ultimatum - 25/04/2007 11:41
Avatar van Ultimatum PHP expert
Citaat:
Hoe kan een site bij sommige mensen heel traag zijn. Is het niet traag bij anderen dan?


Ik weet niet, maar hier op mijn werk is de snelheid gewoon redelijk maar toen mijn baas op een beurs de site liet zien was hij heel traag. Kan ook aan die internet verbinding liggen

Citaat:
Hoeveel queries voer je uit? Vraag je niet onnodig veel dingen op (SELECT *)? Zijn je JOINS correct?


Ik heb redelijk wat queries. Omdat ik op alleen al de begin pagina op 4 verschillende punten in mijn site dingen uit verschillende tabellen moet halen kan ik daar geen joins gebruiken. Ik gebruik al 12 queries op alleen de index (nooit op gelet eerlijk gezegd). En ik gebruik geen joins maar FROM tabel1, tabel2 etc.., is ook een puntje die ik meot veranderen

Citaat:
Maak je gebruik van gzip compression

Wat is dat 

Citaat:
Maak je overbodig gebruik van lussen in je site waar je dit ook stack based kan doen? Maak je gebruik van de constructie "for ($i=0;$i<count($iets);$i++"?


Maak wel gebruik van for loop om alle fouten die in een formulier op treden te laten zien. En als ik het decrementeel maak dan staan de fouten verkeerd om.

Ik ben idd al tegen de fout aangelopen dat ik met mysql_result een error krijg..

Maar dit zijn idd punten waar ik niet helemaal aan had gedacht...
Offline Gerard - 25/04/2007 11:48
Avatar van Gerard Ouwe rakker
Citaat:
Maak wel gebruik van for loop om alle fouten die in een formulier op treden te laten zien. En als ik het decrementeel maak dan staan de fouten verkeerd om.
Het ging mij niet echt daarom, maar het gebruik van PHP.net: count in je expressie zorgt ervoor dat een for-lus 800% meer tijd inneemt.

php code - Bekijk de code zonder highlighting - Klap code in 
  1. <?php
  2.     $iAantal = count($iets);
  3.  
  4.     for ($i=0; $i<$iAantal; $i++)
Heeft dus de voorkeur boven
php code - Bekijk de code zonder highlighting - Klap code in 
  1. <?php
  2.     for ($i=0; $i<count($iets); $i++)


Citaat:
Ik weet niet, maar hier op mijn werk is de snelheid gewoon redelijk maar toen mijn baas op een beurs de site liet zien was hij heel traag. Kan ook aan die internet verbinding liggen
Als je niet precies weet waar het aan ligt, zoek het dan ook niet gelijk bij je code. Wie weet was inderdaad daar de verbinding wel traag, wie weet was op dat moment je eigen webserver verwikkelt in een backup ofzo, weet jij veel.
Offline Ultimatum - 25/04/2007 11:52
Avatar van Ultimatum PHP expert Ow zo, dat van die count moet ik dan weer even fixen 

Nog een vraagje. Ik moet uit een tabel alle velden hebben, en die tabel heeft heel veel velden (geloof me het is waar ). Moet ik dan ook nog SELECT veld1, veld2 etc.. doen of kan ik dan wel gewoon een * doen? Want als ik alle velden dan invul ben ik net zover als alleen een *

Maar ik vond dat de site toch al beetje traag was 
Offline Rens - 25/04/2007 11:59
Avatar van Rens Gouden medaille

Crew algemeen		 Als je echt alle velden moet hebben kun je beter * gebruiken, dan heb je hetzelfde resultaat...
Offline Gerard - 25/04/2007 12:12
Avatar van Gerard Ouwe rakker SELECT * is evil. Ja, je hebt dan alle velden wel gewoon beschikbaar maar als je later naar je code kijkt dien je gelijk de DB erbij te pakken om te zien wat je nu eigenlijk allemaal terugkrijgt.

Ook als je later de database wat uitbreidt met wat velden krijg je deze ook gelijk terug terwijl je ze misschien niet eens nodig hebt.

Ik adviseer dan altijd ook om nooit met SELECT * te werken maar gewoon netjes de velden te vermelden die je nodig hebt.
Offline Thomas - 25/04/2007 12:25
Avatar van Thomas Moderator Met DESCRIBE <je query> kun je zien welke JOINs etc. veel kosten. Deze "dure" kolommen zou je dan kunnen indexeren, waarschijnlijk boek je daarmee (mits je database verder ok is opgezet) wel enige winst.
Offline Ultimatum - 25/04/2007 13:05
Avatar van Ultimatum PHP expert @Proximus, deze tabel heeft (ongeveer) 200 velden. Weet dat het veel is maar heb ze allemaal nodig. (200 is niet precies want is beetje veel om te tellen, kan dus ook stuk meer of stuk minder zijn)

@Fangorn, als ik het goed begrijp moet ik dus elke query apart in phpmyadmin gooien en DESCRIBE ervoor zetten?
Offline Gerard - 25/04/2007 13:12
Avatar van Gerard Ouwe rakker Weet je zeker dat je de database goed hebt genormaliseerd? Kan me niet voorstellen dat je 200 velden nodig hebt.
Gesponsorde links
Dit onderwerp is gesloten.
Actieve forumberichten
© 2002-2024 Sitemasters.be - Regels - Laadtijd: 0.201s