[PHP] Pagina opbouw performance

jbweb schreef op dinsdag 04 september 2007 @ 17:24:

Is er een bepaalde vuist regel welke je toe kan passen om achter de ideale mix van queries en array's te komen?

Meten is weten.

Dat is echt de enige manier om er achter te komen wat sneller is.

daarbij is performance natuurlijk leuk, maar onderhoudbaarheid, een goede opzet van je DB en begrijpelijke code zijn minstens even belangrijk. ik zelf vindt die voorwaarden eigenlijk zelf belangrijker.

ik weet niet hoeveel bezoekers je verwacht, maar zolang dat er geen duizenden per dag zijn maakt het qua serverbelasting niet zoveel uit en of een bezoeker nou 1 of 2 seconden moet wachten tot een pagina geladen is boeit ook niet echt.

Goede CSS scheelt ook veel !

En wat heeft dat met performance van queries te maken ?

[ Voor 54% gewijzigd door whoami op 04-09-2007 20:41 ]

Het ligt er ook aan hoe je server(s) eruit zien. Gebruik je gescheiden database en webservers kan het beter zijn om veel queries te gebruiken, draai je daarentegen je database en je webserver op dezelfde machine, dan kan de performance weer heel anders zijn. Zoals Johnyy al zegt, meten is weten, er is niet echt een vuistregel hiervoor.

Kwestie van de queries testen inderdaad.
timer starten en stoppen na de query en dan het aantal miliseconden (of seconden als het zware queries zijn) vergelijken.

Ik heb hele complexe queries gezien die een eeuwigheid namen om te doen.
Maar daarin werd slecht gebruik gemaakt van index values e.d. waardoor alles on-the-fly met elkaar vergeleken moest worden. Veel Innerjoins er in etc etc.
Totale lengte (70char regel breedte) was ongeveer 100 regels.
Dat was puur om wat artikelen uit een database te trekken, gesorteerd op bepaalde properties (kleurtje dit, prijscategorie dat, that kinda thing, slechts 3 properties en het was onwerkbaar traag)

Oftewel: snelheid is ook afhankelijk van je database design.

maargoed, zoals st0p ook al zegt: als het een seconde langer duurt is dat echt niet belangrijk. Daar wachten users wel op. Als het gaat om tientallen seconden, dan is het inderdaad zinvol om je queries en database structuur te gaan herzien.

Als je database een seconde langer bezig is met 1 bezoeker en je hebt een echt drukke site is dat natuurlijk wel degelijk interessant McKaamos Kijk bijvoorbeeld ook maar naar Hyves of Fok (of hebben ze dat ondertussen wel al wat vlotter gekregen? )

Zelf werk ik het liefst zoveel mogelijk met een template engine die kan cachen, smarty in mijn geval. Zo vaak verandert een menu niet, dus waarom zou je het elke keer uit de database halen? Zelfde voor eigenlijk heel veel gegevens; als je je site daarom goed opbouwt (ook qua templates etc dus) kun je vaak al veel meer snelheidswinst halen.

Dit valt trouwens ook te doen in je database model zelf. Een mooi voorbeeld is een forum: je kan voor elke pageview gaan kijken wanneer de laatste post binnen een catagorie geweest is. Wordt al wat naarder als je ook subcatagorieen hebt aangezien je dan een redelijk complexe lange query krijgt om al die catagorieen bij langs te gaan. vBulletin bijvoorbeeld heeft dat afgevangen door simpelweg een extra veld toe te voegen aan hun catagorie-tabel met de datum van de laatste post - elke keer dat er een post gemaakt wordt krijgt ook zijn catagorie tabel daarna een update. Scheelt je bij een groot forum zo 40 subqueries per pageview, dat zijn toch de dingen die wel tellen

Natuurlijk, je hebt kans dat een script crashed tussen de twee updates (niet zoveel, maargoed, it could happen ) maar daarvoor zit er heel simpel in het adminpanel een pagina functies om dat te controleren en indien nodig te verbeteren. Handig af en toe te runnen en kost dan ook wel echt veel tijd, maar daar hebben je users geen last van

[ Voor 11% gewijzigd door FragFrog op 04-09-2007 19:05 ]

Alle gerelateerde informatie in een query doen is mijn vuistregel. Hooguit splits ik statistische versus feitelijke data, dus aparte queries voor het totaal van verkopen en de laatste tien verkopen als ik die in een scherm toon.

Als ik ook een lijst met online gebruikers wil laten zien...dan doe ik die apart.....

Vuistregel die ik hanteer is gewoon wat hoort bij elkaar + wat verandert. Het menu + content ophalen zou ik nooit doen, omdat in 90% van de gevallen het menu hetzelfde blijft ( waardoor mysql/ik deze query mooi kan cachen ) terwijl de content bijna altijd veranderd.

Bijv bij de frontpage van tweakers zou ik me kunnen voorstellen dat het menu opgehaald wordt uit cache, content wordt opgehaald uit cache, reacties worden opgehaald uit cache , linkerkant wordt opgehaald uit cache.
Gewoon volgens de volgende logica :
Menu heb je maar 3 of 4 varianten van ( niet-ingelogd, wel-ingelogd, redacteur en admin )
Content wordt maar 1x geplaatst en is daarna bijna altijd hetzelfde. ( wijziging invalideert gewoon de cache )
Reacties zijn heel vaak hetzelfde ( toevoegen van een reactie / modbreak invalideert de cache, tonen / niet tonen adhv preferences zou ik met css doen )
Linkerkant heb je qua gegevens ook maar een x aantal varianten van de gewoon invalidated bij cache kunnen worden.

Dus heel simpel gezegd : zo min mogelijk queries die zo goed mogelijk te cachen zijn.

jbweb schreef op woensdag 05 september 2007 @ 09:39:
Oké, begint een mooi verhaal te worden. En de perfecte code bestaat dus niet (logisch)!

Normaal gesproken ontwikkel ik voor zowel gecombineerde servers en clusters met aparte web,- database servers. In principe zou hiervoor dus verschillende code geschreven moeten worden om het onderste uit de kan te halen.

Wat mij wel opvalt is dat er zoveel reacties zijn over het cachen van gegevens. Om eerlijk te zijn ben ik hiermee nauwelijks bekend als het om PHP/MySQL gaat. Ik zag Smarty ergens langskomen, moet ik dus maar eens op gaan zoeken. Zijn er nog andere mogelijkheden in cachen, of programma's? Hoe werkt dit precies?

Simpele definitie van caching is gewoon dat je van lange / kostbare bewerkingen het resultaat opslaat zodat bij de volgende alleen het resultaat opgehaald wordt en de bewerking niet meer hoeft plaats te vinden.

Dus bijv, jij hebt een query die 10 sec duurt om te draaien, dit is niet erg om zo af en toe te laten zien, maar als elke gebruiker 10 sec moet wachten dan is het hardstikke irritant, dan kan je eens gaan nadenken. Hoe vaak moeten die gegevens echt ververst worden, zeg je bijv dat 1x per 10 minuten ook goed is, dan maak je gewoon in je php-code een if-constructie om je mysql_query heen dat eerst kijkt of er een bestand bestaat wat de laatste 10 minuten aangemaakt is. Nee, dan draai je de query en wacht de gebruiker 10 sec en schrijf je het resultaat weg naar het bestand ( zodat het volgende keer wel bestaat ), ja dan toon je gewoon de inhoud van het bestand ( gebruiker hoeft nergens op te wachten )

Je zou kunnen zeggen dat als je erg weinig UPDATE en INSERT acties hebt, maar heel veel SELECT op een table, dat je hem gewoon hard wegschrijft of cached, dat duurt langer als iemand in de admin eens een keertje wat aanpast, maar verder is het dan altijd sneller.

Houd wel een beetje in de gaten dat het ook belangrijk is dat je niet te veel werk gaat verrichten voor bijna hypothetische verbeteringen aan performance.

[ Voor 23% gewijzigd door BikkelZ op 05-09-2007 16:24 ]