[PHP] Code is te langzaam

[AngelDust]

Ik zit met een probleem, ik heb een tabel waar nu al 10.000 entry's instaan, en dit groeid erg snel. Nu heb ik een script om de laatste 6 reacties op te halen, alleen ik vind het script veel te langzaam. Het kost me server nu al 0.050 seconden om het uit te voeren.

Ik heb dit script zo gemaakt dat ik dacht dat het niet sneller zou kunnen, maar dat vast wel. Dus hierbij vraag ik of iemand weet hoe ik het beter aan kan pakken.

PHP:

$result = mysql_query('SELECT id,date,cato,nieuws_id,titel FROM reacties ORDER BY date DESC LIMIT 6');
while ($row = mysql_fetch_array($result, MYSQL_ASSOC)) {

$nieuws_id = $row['nieuws_id'];
$ida = $row['id'];

if($row['cato'] == "1") {
$link = "/tweaks/bekijk/$nieuws_id";
$onwerp = 'Tweak';
}
if($row['cato'] == 2) {
$link = "/downloads/bekijk/$nieuws_id#$ida";
$onwerp = "Download";
}
if($row['cato'] == 3) {
$link = "/review/bekijk/review/$nieuws_id/1/true#$ida";
$onwerp = "Review";
}
if($row['cato'] == 4) {
$link = "/tutorial/bekijk/tutorial/$nieuws_id/1/true#$ida";
$onwerp = "Tutorial";
}
if($row['cato'] == 5) {
$link = "/nieuws/bekijk/$nieuws_id#$ida";
$onwerp = "Nieuws";
}
if($row['cato'] == 6) {
$link = "/casemods/bekijk/$nieuws_id#$ida";
$onwerp = "Casemod";
}
if($row['cato'] == 7) {
$link = "/poll.php?id=$nieuws_id#$ida";
$onwerp = "Poll";
}
if($row['cato'] == 8) {
$link = "/extra/crew/$nieuws_id#$ida";
$onwerp = "Crew Lid";
}
if($row['cato'] == 9) {
$link = "/scripts/bekijk/$nieuws_id#$ida";
$onwerp = "Script";
}
if($row['cato'] == 10) {
$link = "/tips/bekijk/$nieuws_id#$ida";
$onwerp = "Tips & Tricks";
}


   echo date("H:i", $row['date']) .' <a onmouseover="window.status=\''. $row['titel'] .' [ '. $onwerp .' ]\';return true" title="'. stripslashes($row['titel']) .' [ '. $onwerp .' ]" href="'. $link .'" class="menu">'. substr(stripslashes($row['titel']), 0, 19) . '</a>
';


}

Het gaat dus om de tabel reacties, en er kan gereageerd worden op 10 verschillende soorten pagina's. Welke pagina dat is wordt in de database aangegeven dmv "cato".

[SWfreak]

Erhm, ipv telkens if elseif gebruiken? switch-statement er van bakken?

[whoami]

Ik denk niet dat de grootte performance winst uit uw script zal te halen zijn (ik heb het nog niet bekeken), maar eerder uit uw sql-query of databank.

Heb je indexen op die reactie-tabel liggen? Meer specifiek op het veld date dan? Je sorteert nl. op dat veld en dan wil je enkel de eerste 6 reacties hebben.
Dwz dat het DBMS eerst alle records uit die tabel zal moeten sorteren, en als er geen index op ligt, dan kan dat wel eens trager gaan...

[marty]

waarom doe je trouwens stripslashes bij de titel? lijkt me ook overbodig.

[ikke007]

als het langzaam wordt omdat je database groot is ligt het niet aan je code, het is je sql querie / database.

ga dus eens na wat je hier in kan versnellen

misschien de laatste 6 berichten in een aparte tabel plaatsen zodat hij die snel kan uitlezen?

[ Voor 57% gewijzigd door ikke007 op 10-01-2003 10:51 ]

[Verwijderd]

Als je een index op je datumveld hebt kan je het volgende doen.

"WHERE date BETWEEN unix_timestamp()-(86400*7) AND unix_timestamp()"

Dit is in het geval van een unix_timestamp(). Dan leest ie enkel de velden van de laatste 7 dagen ipv alle 10000 en dan hoef je geen extra velden toe te voegen.

[Verwijderd]

NIet als flame bedoeld, maar als je dan echt sneller wilt gooi je php aan de kant en ga je over op JSP, zorg dat je een JVM installeerd met een JIT compiler en je je script kan haast niet sneller worden uitgevoerd.

Verder is het terecht dt de andere gebruikers opmerken dat je is moet kijken naar je database.

[edie]

LIMIT
Probeer eens SELECT TOP 6 ....

[D2k]

eddie19 schreef op 10 January 2003 @ 11:32:
LIMIT
Probeer eens SELECT TOP 6 ....

mysql != mssql

[Creepy]

Verwijderd schreef op 10 January 2003 @ 11:08:
NIet als flame bedoeld, maar als je dan echt sneller wilt gooi je php aan de kant en ga je over op JSP, zorg dat je een JVM installeerd met een JIT compiler en je je script kan haast niet sneller worden uitgevoerd.

En anders ga je over op CGI met een stuk C-code dat je dan ook nog eens laat optimaliseren voor de processor waar je op draait.... en ook dan merk je dat de snelheids winst t.o.v. PHP MINIMAAL is, en de meeste vertraging toch echt in het bevragen en gebruiken van de database zit.

[edie]

D2k schreef op 10 January 2003 @ 11:35:

[...]

mysql != mssql

TOP 6 kennen alle DBMS'sen waar ik tot nu toe mee heb gewerkt; LIMIT niet.

@topicstarter: Vraag eens op hoeveel records je terugkrijgt en hoelang je over het select statement doet.

[ Voor 2% gewijzigd door edie op 10-01-2003 11:41 . Reden: tiepfout ]

[D2k]

eddie19 schreef op 10 januari 2003 @ 11:40:
[...]

TOP 6 kennen alle DBMS'sen waar ik tot nu toe mee heb gewerkt; LIMIT niet.

@topicstarter: Vraag eens op hoeveel records je terugkrijgt en hoelang je over het select statement doet.

ja maar dat zeg ik toch mysql niet.

[edie]

D2k schreef op 10 January 2003 @ 11:42:

[...]

ja maar dat zeg ik toch mysql niet.

mysql kent geen TOP 6
Bron?

[Creepy]

eddie19 schreef op 10 januari 2003 @ 11:44:
[...]

mysql kent geen TOP 6
Bron?

Gewoon de MySQL documentatie..
http://www.mysql.com/doc/en/SELECT.html

[D2k]

eddie19 schreef op 10 January 2003 @ 11:44:
[...]

mysql kent geen TOP 6
Bron?

http://www.mysql.com/doc/en/SELECT.html
en nu weer ontopic svp

[whoami]

Verwijderd schreef op 10 januari 2003 @ 10:56:
Als je een index op je datumveld hebt kan je het volgende doen.

"WHERE date BETWEEN unix_timestamp()-(86400*7) AND unix_timestamp()"

Dit is in het geval van een unix_timestamp(). Dan leest ie enkel de velden van de laatste 7 dagen ipv alle 10000 en dan hoef je geen extra velden toe te voegen.

Tja, je kunt op die manier natuurlijk al een schifting maken in het aantal rows die moeten opgezocht worden, maar de topicstarter wil de laatste 6 reacties.... Stel nu dat er in de laatste 7 dagen geen enkele keer gereageerd werd, dan gaan er ook geen rows gereturned worden...
Zowiezo moet er een index op die 'datum' column. Ik weet niet of MySQL iets heeft zoals de 'clustered index' in MS SQL Server. Als MySQL zoiets heeft, dan is het misschien wel het overwegen waard om een 'clustered index' op die datum column te leggen.

[Creepy]

D2k schreef op 10 January 2003 @ 11:47:

[...]

http://www.mysql.com/doc/en/SELECT.html
en nu weer ontopic svp

[nog 1 offtopic]
Trage donder
[/nog 1 offtopic]
Overigens zijn zowel TOP als LIMIT geen ANSI SQL.

[Verwijderd]

Creepy schreef op 10 January 2003 @ 11:37:
[...]

En anders ga je over op CGI met een stuk C-code dat je dan ook nog eens laat optimaliseren voor de processor waar je op draait.... en ook dan merk je dat de snelheids winst t.o.v. PHP MINIMAAL is, en de meeste vertraging toch echt in het bevragen en gebruiken van de database zit.

CGI is de traagste van allemaal, voor elke request wordt een apparte system thread gestart. Meestal duurt het opzetten van de environment langer dat het parsen van het script.

[whoami]

Ik denk dat we hier een beetje erg offtopic aan het gaan zijn.

De topicstarter doet het in PHP. Hij zal daar waarschijnlijk wel een reden voor hebben, dus is het niet aan de orde om hier te gaan beargumenteren welke andere taal een sneller stuk code zou kunnen opleveren.

De grootste snelheidswinst zal toch uit die databank/query te halen zijn.

[Creepy]

Verwijderd schreef op 10 januari 2003 @ 11:51:
[...]

CGI is de traagste van allemaal, voor elke request wordt een apparte system thread gestart. Meestal duurt het opzetten van de environment langer dat het parsen van het script.

Dus het opstarten van een servlet, deze jitten, dan uitvoeren is sneller dan het starten van een thread en hierin een native executable uitvoeren?

[D2k]

Creepy schreef op 10 januari 2003 @ 11:53:
[...]

Dus het opstarten van een servlet, deze jitten, dan uitvoeren is sneller dan het starten van een thread en hierin een native executable uitvoeren?

ik was bezig met een zelfde reply
C optimisen via ASM (voor de echte bikkels) is ongetwijfeld sneller

[Verwijderd]

Verwijderd schreef op 10 January 2003 @ 11:08:
NIet als flame bedoeld, maar als je dan echt sneller wilt gooi je php aan de kant en ga je over op JSP, zorg dat je een JVM installeerd met een JIT compiler en je je script kan haast niet sneller worden uitgevoerd.

Verder is het terecht dt de andere gebruikers opmerken dat je is moet kijken naar je database.

Dit vindt ik eerlijk gezegd een beetje domme opmerking (niet als flame bedoeld). JSP is totaal anders dan PHP. Voor JSP heb je JAVA kennis nodig en dit gaat iets verder dan PHP. Het is dus dom om te zeggen "je kunt beter 'gewoon' je site in JSP omzetten". Ook qua configuratie van de server is dit totaal anders.

Trouwens, jsp is niet per definitie sneller dan php. Ligt inderdaad aan de opbouw van je database en hoe de code van PHP/JSP is opgebouwd. Als dit alles optimaal is dan zal php echt niet langzamer (niet merkbaar langzamer) zijn dan JSP.

Om op de vraag terug te komen, ik zou inderdaad die if-else lussen veranderen in een switch-statement. Snelheid zal inderdaad waarschijnlijk in de database zitten.

[Nielsz]

En maak voor de gein eens een array:

$blaat[1]['link']="/tweaks/bekijk/$nieuws_id";
$blaat[1]['onwerp']=$onwerp = 'Tweak';


En dat voor elke keuze natuurlijk
Dat zal niet heel veel sneller zijn, maar wel mooier.

[edie]

Nielsz schreef op 10 januari 2003 @ 12:10:
En maak voor de gein eens een array:

$blaat[1]['link']="/tweaks/bekijk/$nieuws_id";
$blaat[1]['onwerp']=$onwerp = 'Tweak';


En dat voor elke keuze natuurlijk
Dat zal niet heel veel sneller zijn, maar wel mooier.

Nog beter/mooier:

Maak een categorietabel en join daar op. Heb je al die if's niet meer nodig

[Verwijderd]

Nielsz schreef op 10 January 2003 @ 12:10:
En maak voor de gein eens een array:

$blaat[1]['link']="/tweaks/bekijk/$nieuws_id";
$blaat[1]['onwerp']=$onwerp = 'Tweak';


En dat voor elke keuze natuurlijk
Dat zal niet heel veel sneller zijn, maar wel mooier.

En dan $blaat[$row['cato']] aanroepen? Ik denk wel dat het sneller zou zijn.

[Altaphista]

dan is de query weer langzamer toch? En daar moet je juist de tijdwinst op pakken.
Wat ook helpt is: naast indexeren je 'titel' bijvoorbeeld varchar(20) maken ipv varchar(50), als je niet meer dan 20 nodig hebt (dit zijn wel beginnersdingen, en ik weet niet of het van toepassing is op jou ) (ik ben nog op zoek naar een link waar ik het heb gelezen)

edit: Ik weet niet of je er wat aan hebt: http://www-mrim.imag.fr/r...nuel_toc.html#Performance (en dan vooral: http://www-mrim.imag.fr/r...el_Optimize.html#Optimize)

[ Voor 26% gewijzigd door Altaphista op 10-01-2003 13:53 . Reden: link toegevoegd ]

[whoami]

Altaphista schreef op 10 January 2003 @ 13:49:
naast indexeren je 'titel' bijvoorbeeld varchar(20) maken ipv varchar(50), als je niet meer dan 20 nodig hebt (dit zijn wel beginnersdingen, en ik weet niet of het van toepassing is op jou ) (ik ben nog op zoek naar een link waar ik het heb gelezen)

Dat zou niet mogen uitmaken. VarChar gaat enkel het aantal werkelijk nodige karakters fysiek opslaan. Als je dus een varchar(50) hebt, en je slaat er iets in op met een lengte van 20, dan zullen die andere 30 karakters niet opgevuld worden ofzo.

[Altaphista]

whoami schreef op 10 January 2003 @ 13:52:

[...]


Dat zou niet mogen uitmaken. VarChar gaat enkel het aantal werkelijk nodige karakters fysiek opslaan. Als je dus een varchar(50) hebt, en je slaat er iets in op met een lengte van 20, dan zullen die andere 30 karakters niet opgevuld worden ofzo.

ja klopt, kbedoelde meer nr 2 van mijn links zie boven

[AngelDust]

Het probleem is reeds opgelost..

[Nielsz]

Verwijderd schreef op 10 januari 2003 @ 13:32:
[...]


En dan $blaat[$row['cato']] aanroepen? Ik denk wel dat het sneller zou zijn.

Zo ongeveer ja
Want je gaat telkens die switch uitvoeren in de loop, en dat is natuurlijk niet snel. Dus die array aanmaken boven de loop, en in de loop daar alleen maar aan refereren.

[Verwijderd]

AngelDust schreef op 10 January 2003 @ 13:56:
Het probleem is reeds opgelost..

Maar wat heb je er aan veranderd?
Kan de volgende die met dit probleem zit het oplossen dmv de search....

[ Voor 41% gewijzigd door Verwijderd op 10-01-2003 13:59 . Reden: quote toegevoegd ]

[Verwijderd]

De maximale lengte van een varchar kleiner maken zou niet uit moeten maken. Daarom is het een varchar. Een char is echter vele malen sneller maar in dit geval maakt dat niks uit want deze query doet alleen een ORDER BY date.

- Ik zou van al die if's een switch/case statement maken met breaks. Dan hoeft hij niet elke keer de rest van de if's door als hij erboven al afgehandeld is.

- Alles wat je alvast in MySQL kunt doen is sneller dan achteraf in PHP. Die datum opmaak date("H:i", $row['date']) kun je ook alvast in MySQL doen met zoiets als DATE_FORMAT(date, '%H:%i') as date_formatted.

[Nielsz]

Ja, dan is het alleen jammer dat je queries moet aanpassen als je de layout wilt veranderen.

[Erkens]

Creepy schreef op 10 January 2003 @ 11:53:
[...]

Dus het opstarten van een servlet, deze jitten, dan uitvoeren is sneller dan het starten van een thread en hierin een native executable uitvoeren?

offtopic:
een servlet blijft actief
hoeft dus enkel 1x gestart te worden en daardoor zal de eerste aanvraag langer duren

[Glimi]

Erkens schreef op 10 January 2003 @ 15:44:

offtopic:
een servlet blijft actief
hoeft dus enkel 1x gestart te worden en daardoor zal de eerste aanvraag langer duren

offtopic:
Onzin. Een servlet wordt de eerste keer naar een .class file(s) gecompileerd. Het executen, classloaden, checken, thread starten, jitten ed van die servlet zal altijd opnieuw gebeuren bij een nieuwe aanroep. In zekere mate kan dit gecached worden

[Erkens]

Glimi schreef op 10 januari 2003 @ 15:51:

[...]

offtopic:
Onzin. Een servlet wordt de eerste keer naar een .class file(s) gecompileerd. Het executen, classloaden, checken, thread starten, jitten ed van die servlet zal altijd opnieuw gebeuren bij een nieuwe aanroep. In zekere mate kan dit gecached worden

offtopic:
pardon? ik zit dat ding zelf te compilen naar servlet (=class), jij hebt het nu over jsp
moet je voor de grap eens kijken op onze server, voor elke servlet draait er een thread