wat werkt vertragend
Ik zou wel eens willen wat tijdens één pagina-aanroep vertragend werkt. Op het moment dat je een pagina-aanroep doet, welke factoren werken dan echt vertragend?
Ik weet dat je bijvoorbeeld niet te veel afzonderlijke css en javascript bestanden moet inladen, en ook niet te veel afzonderlijke images.
Maar wat ik bijvoorbeeld niet weet...
1) hoeveel database aanroepen kun je doen tijdens één pagina-aanroep zonder dat dit vertragend werkt? 1, 5, 10, 20, 100?
2) hoeveel bestanden kun je includen zonder dat dit vertragend werkt? Ik heb wel eens gehoord dat sommige frameworks 100'en bestanden includen?
Ik stel deze vraag vanwege o.a. de volgende reden. Ik heb nu een VPS en de bedoeling is dat daar uiteindelijk meerdere sites op gaan draaien.
Nu zit ik zomaar wat te brainstormen en heb ik het idee om bij iedere pagina-aanroep de domeinnaam (die ik uit de URL filter) door een database te halen en een aantal controles uit te voeren. Bijvoorbeeld of de betreffende website wel of niet geactiveerd is (stel dat een klant bijv. te laat betaalt dan kan ik de domeinnaam deactiveren). Maar ook bijv. om te kijken wat voor type website het is. Stel dat het bijv. een webshop is, dan moet ik andere routes inladen dan wanneer het een 'standaard' website is. Nu vraag ik me af of zo'n controle via de database erg belastend is. Als je dit bij iedere pagina-aanroep doet, zou dat dan vertragend werken? Ik kan ook na de 1e aanroep de gegevens in de Sessie zetten, zodat ik de controle slechts 1x keer per sessie hoef uit te voeren. Alleen ben ik dan wel verplicht om voor iedere pagina-request een sessie aan te maken. Hoe zouden jullie dat doen? Bij iedere pagina-aanroep de database raadplegen, of 1x per sessie maar dan wel altijd een sessie bestand moeten aanmaken?
Ozzie PHP op 10/01/2013 23:25:00:
1) hoeveel database aanroepen kun je doen tijdens één pagina-aanroep zonder dat dit vertragend werkt? 1, 5, 10, 20, 100?
Met of zonder indexen op de juiste kolommen? Met of zonder complexe joins? Met of zonder subqueries? Met 10 records in de tabel, of 10.000.000? Begrijp je het punt?
En dan wat echt vertragend werkt, een cURL request uitvoeren.
Tja, je vraag is zo algemeen, daar is in feite geen antwoord op te geven.
Ozzie PHP op 10/01/2013 23:33:38:
Dan kun je 150 tot 400 queries per pagina uitvoeren, alleen heb je dat bij 2.000 records vermoedelijk niet nodig. Probeer wel je databases te normaliseren en je queries te optimaliseren (en dan kan ik me niet voorstellen dat je slechts simpele SELECTs hebt).Maar stel dat de indexen goed staan en de queries redelijk simpel zijn (simpele SELECT queries) en de betreffende tabel is maximaal 2000 records?
Het aantal includes is afhankelijk van de hardware (SSD-hosting is in de mode), het besturingssysteem, het bestandssysteem en de directorystructuur. Vanaf ongeveer 100 includes worden afnemende prestaties meetbaar, maar elke extra include is er natuurlijk altijd één meer.
Hier zijn nog wat optimalisaties mogelijk. Vanwege de aanvullende controles zijn include() and require() efficiënter dan include_once() and require_once(). Verder kun je beter volledige paden gebruiken dan relatieve paden (omdat die opgelost moeten worden).
Leuke benchmarks voor van die typische PHP-vragen:
http://www.blueshoes.org/phpBench.php
150 tot 400 queries? Kijk daar heb ik wat aan. Zoveel queries zou ik nooit uitvoeren in 1 pagina-aanroep. Maar ik was vooral erg benieuwd. Toen ik net begon met programmeren, werd er altijd geroepen dat je zo weinig mogelijk database aanroepen moest doen, omdat dat ten koste gaat van de performance. Dus ik had altijd het idee dat als je per pagina-aanroep de database 5 keer zou aanroepen, dat dat dan al vertragend zou gaan werken. Maar dat valt dus weer mee :)
Leuke link trouwens. Wat me opviel was dat bij de allerlaatste test is dat in een vergelijking === sneller is dan ==. Dat verbaast me eigenlijk wel, omdat er bij === toch een extra controle plaatsvindt (op type)? Iemand die dat kan verklaren?
Het klinkt mij logischer dat === sneller is dan ==. === is 100% exact hetzelfde, waar == niet gevoelig is voor bijvoorbeeld hoofdletters etc. Dus daar kan meer variatie inzitten, dan in een 100% vergelijking.
Bij === is het simpelweg wel of geen match
Bij == zijn meerdere mogelijkheden voor een match
Zie het als kleuren vergelijken.
bij === is groen gewoon groen en is snel te zien
bij == is het groen, maar kan ook licht groen zijn of donkergroen waar dus meer mogelijkheden zijn en dus meer tijd kost.
Code (php)
Gewijzigd op 11/01/2013 13:51:38 door Ward van der Put
Ik ging uit van het omgekeerde, namelijk
if (2 == 2)
Hier hoeft alleen gecontroleerd te worden of 2 gelijk is aan 2, en er hoeft niet gecontroleerd te worden of het type (in dit geval een int) hetzelfde is. Dat scheelt dus weer een controle. Zo heb ik het altijd gedacht.
Ik gebruikte dus bewust vaker == in plaats van === omdat ik dacht dat dat sneller zou zijn. Om er dus vandaag achter te komen dat het precies omgedraaid is... krijg nou wat :-)
Ozzie PHP op 11/01/2013 13:19:22:
150 tot 400 queries? Kijk daar heb ik wat aan. Zoveel queries zou ik nooit uitvoeren in 1 pagina-aanroep. Maar ik was vooral erg benieuwd. Toen ik net begon met programmeren, werd er altijd geroepen dat je zo weinig mogelijk database aanroepen moest doen, omdat dat ten koste gaat van de performance. Dus ik had altijd het idee dat als je per pagina-aanroep de database 5 keer zou aanroepen, dat dat dan al vertragend zou gaan werken. Maar dat valt dus weer mee :)
Je moet er rekening mee houden dat elke database aanroep een client-server interactie is. Het gaat erom waarmee je het vergelijkt.
Regelmatig zie je dat er queries worden uitgevoerd in while lus op het resultaat uit een andere query, terwijl dit net zo makkelijk in 1 query kan.
Dan krijg je bv het verschil tussen 1 en 21 query's en dat spaart je dus 20 keer de client_server interactie uit.
Ik snap dat je altijd zo efficiënt moelijk moet omgaan met je code en met database aanroepen. Maar ik vroeg me dus af (zie het onderste stuk in mijn beginpost) of het vertragend werkt als ik bij iedere pagina-aanroep een controle uitvoer, óf dat ik beter 1x een aanroep kan doen en de resultaten opsla in een sessie. Dit laatste houdt dan wel in dat je altijd een sessiebestand moet aanmaken, ongeacht of iemand wel of niet is ingelogd. Wat heeft in dit specifieke geval jouw voorkeur?
Dus als er gebruiker inlogt een sessie aanmaken, en op pagina's waar gebruikers specifieke gegevens getoond dan gewijzigd kunnen worden die controle uitvoeren.
Zo'n vertraging is hooguit een tiende seconde, dus imo te verwaarlozen.
Maar over het algemeen kan je stellen dat het werken met sessies sneller is dan werken met een database (hetgeen absoluut niet wil zeggen dat je de gehele database in een sessie moet zetten :-P), want sessies zijn op bestandsniveau.
Het is situatie afhankelijk.
Met andere woorden, er is op jouw algemene vraag geen algemeen antwoord mogelijk.
Dan kan je alle query's optimaliseren maar dan moet je toch andere technieken gaan toepassen. Of oneindig hardware / geheugen bij prikken. Dat is natuurlijk wel behoorlijk prijzig dus dan kom je al gauw weer uit op een systeempje met loadbalancers en een cachingplatform.
Snap je wat ik bedoel?
Het gaat er mij vooral om waar ik rekening mee moet houden. En in dit specifieke geval is mijn vraag:
Ik wil het type site bepalen zodat het systeem weet welke routes moeten worden ingeladen. Dit type is opgeslagen in de database. Is het nu het slimst om bij iedere pagina-aanroep het type op te halen uit de database, of is het slimmer om het eenmalig (per sessie) op te halen en op te slaan in een sessie? Dan hoef je dus niet bij iedere pagina-aanroep het type uit de database op te vragen, maar het betekent wel dat er altijd een sessie(bestand) wordt aangemaakt (zelfs als je in je applicatie nergens anders sessievariabelen zou gebruiken). Wat is dan de slimste optie? Iedere keer ophalen uit de database, of 1x ophalen en opslaan in sessie (maar dan dus wel altijd een sessie moeten aanmaken)?