veel...!
Vaak krijg ik dan het antwoord dat ik me over veel dingen niet druk hoef te maken, omdat ze hartstikke snel gaan, vrijwel geen tijd kosten, en dus geen negatieve invloed op de performance hebben. En dat bracht mij zojuist op een (vind ik) superleuke vraag! Namelijk... wat gebeurt er op jouw website als er 1 pagina wordt aangeroepen? Daar ben ik superbenieuwd naar.
Dus wat heb ik gedaan? Welnu, het volgende. Ik heb een lijstje gemaakt met een aantal punten waarvan ik denk dat ze relatief best "veel" tijd kosten. En de vraag is nu of jij, ja jij, de aantallen wil invullen en wil aangeven om wat voor site het gaat (bijv. een webshop, een algemene site met bedrijfsinformatie enz.). Hoe meer mensen de lijst invullen, des te beter inzicht we krijgen in de processen die plaatsvinden en des te beter ik zelf kan instellen wat veel en wat weinig is. Ik hoop dat dit een heel leuk topic wordt. De aantallen hoeven overigens niet exact te kloppen. Het gaat om een globale benadering. Hier is de lijst!
- Wat voor website is het? (een korte algemene omschrijving. De url en bedrijfsnaam hoef je niet te noemen.)
Onderstaande vragen hebben betrekking op 1 pagina aanroep.
- Hoeveel database acties vinden er gemiddeld plaats?
- Hoeveel records worden daarbij ongeveer doorzocht? (bijv. 50 users is 50 records)
- Hoeveel javascript bestanden worden er ingeladen?
- Hoeveel css bestanden worden er ingeladen?
- Hoeveel verschillende (php) bestanden worden er ge-include of required? (Indien je objectgeoriënteerd programmeert denk dan ook aan al je classes.)
- Maak je gebruik van caching? (van database gegevens of complete html pagina's)
- Indien je objectgeoriënteerd programmeert: hoeveel objecten worden er tijdens een pagina aanroep aangemaakt? (moeilijke vraag, maar doe eens een schatting)
- Doe je iets speciaals om je website zo snel mogelijk te houden (zo ja, wat?) of ben je daar niet bewust mee bezig?
INVULLEN MAAR! :-)
Maar ik wil wel een aantal dingen toelichten. Het gaat in dit geval om een platform voor een webshop gebouwd op Zend Framework.
Database aanroepen
Heel weinig! Alle resultsets worden gecached (minimaal 5 minuten) maximaal 15 minuten met APC (user) cache. Alleen de inhoud van de winkelwagen wordt wel elke pagina opgehaald. In een ideale situatie (dus bij een goed gevulde cache) wordt ongeveer 70% van de gegevens uit APC gehaald en zijn er maar 30% database roundtrips, dus laten we zeggen 5 queries?
Hoeveel records worden doorzocht?
Geen idee, verschilt dus ook per page request, cache validatie, etc. Niet echt te beantwoorden :-(
Hoeveel JavaScript/CSS bestanden worden er ingeladen?
Heleboel, ongeveer 10/25 bestanden denk ik. MAAR ik gebruik mod_pagespeed, en die zorgt ervoor dat alle CSS bestanden bij elkaar gegooit worden, minified en gzipped. Zelfde geld voor javascript dus uiteindelijk maar 2 requests ;)
Hoeveel PHP bestanden worden er geinclude?
Wat heeft dit met performance te maken? Hooguit memory usage, en ik gebruik APC opcode caching dus is het geheugen gebruik minimaal (gemiddeld zo'n 10-20mb). Met een Framework is niet te achterhalen hoeveel bestanden er include worden ivm autoloaders e.d.
Maak je gebruik van caching?
Ja dus. APC opcode caching, user cache (voornamelijk voor database data) en mod_pagespeed die plaatjes, css, etc cached.
Indien je objectgeoriënteerd programmeert: hoeveel objecten worden er tijdens een pagina aanroep aangemaakt?
Haha, grapjas. 100.000 ofzo?
Doe je iets speciaals om je website zo snel mogelijk te houden (zo ja, wat?) of ben je daar niet bewust mee bezig?
Jazeker! Pas geleden APC user caching dus geïntroduceerd, wat echt enorm veel scheelt, van 0.6 sec naar 0.2 seconde, en wil ook dingen met varnisch en load balancing of mysql-clustering doen als de klant daar akkoord op geeft.
Als jij wilt weten overigens welke PHP code in je software 'traag' is, zou ik eens kijken naar xdebug-profiler met kcachegrind. Xdebug-profiler profileert elke functie aanroep in je code (inclusief PHP functies zelf) en met kcachegrind kun je in grafieken en e.d. zien welke gedeeltes van je software echt langzaam zijn of veel geheugen gebruiken etc. Erg handig :) In plaats van kCacheGrind kun je ook WebGrind gebruiken wat een web applicatie is.
Thanks Kees! Ook al kon je niet alle vragen beantwoorden :) Ik probeer gewoon wat inzicht te krijgen voor m'n algemene beeldvorming en ik vind dit dus wel razend interessant! 100.000 objecten??? Is that for real????????????? :-|
Ik denk dat je van dat nummer niet zo moet schrikken, als je in Java met Hibernate en Spring werkt zit je ook in de honderduizenden objecten terwijl het wel gewoon nog snel is..
Even offtopic: Kees Schepers: hoe en waar zet je die mod_pagespeed aan?
@Kees: oh oke... dan hoef ik me voorlopig geen zorgen te maken over mijn objecten :D
Eddy Erkelens op 22/02/2012 10:11:53:
Even offtopic: Kees Schepers: hoe en waar zet je die mod_pagespeed aan?
Dat is een apache module, net zoals PHP dat is in apache. Je kunt het tegenwoordig al vaak installeren via de package managers (yum, node, apt-get, etc) of via Google zelf downloaden en compileren (is vrij eenvoudig hoor).
Dan maakt hij een pagespeed.conf aan in je conf.d folder en daar kun je allerlei instellingen aanpassen.
Ik heb nog geen eigen website, hoop die dit jaar wel te krijgen, maar toch hier wat inzichten van mijn kant:
Hoeveel javascript bestanden worden er ingeladen?
Vaak 2, waarvan 1 sowieso gecached:
- 1 met een framework erin, als Dojo of MooTools (jQuery tegenwoordig wat minder)
- 1 met de scripts erin
(- 1 met de plugins)
Hoeveel css bestanden worden er ingeladen?
Probeer dit te houden op 1. Probeer doormiddel van tools als SASS, Stylus of LESS deze bestanden de comprimeren en met deze tools kun je ook verschillende bestanden mooi uit elkaar houden, terwijl die in de publieke website 1 bestand worden.
Hoeveel verschillende (php) bestanden worden er ge-include of required?
Heel wat, maar dat maakt natuurlijk niks uit.
Doe je iets speciaals om je website zo snel mogelijk te houden (zo ja, wat?) of ben je daar niet bewust mee bezig?
Ja, ik gebruik altijd tools als:
- HTML5 boilerplate BUILD script (deze JAVA tool comprimeerd en minified JS en CSS files met YUI compressor, minified images, comprimeerd HTML (dit kan je zelf op verschillende niveau's instellen), zorgt voor optimalisatie van pagina's en nog veel meer).
- YUI compressor
- Smush it (kleine tool van Yahoo om afbeelding lossless te comprimeren)
En verder kan ik je de chrome dev. tools aanraden. Dit is de Firebug van Chrome. Deze bevat hele handige tabs waarmee je de snelheid van je JS, CSS (denk aan optimalisatie selectors) en afbeeldingen optimaliseert. Het registreert alles wat je doet en daarmee kun je kijken of je misschien in je JS per ongeluk eerst paint dan wat parsed, dan weer paint en dan weer wat parsed. Je kunt beter eerst alles parsen en dan alles painten.
Thanks Wouter!
Goede tip, thanks!