[PHP - MYSQL] Perfomance vraag (Database vs Filesystem)

[soepah]

Ik ben gevraagd een webshop te maken voor een kennis, Ik heb eerder wel het een en ander gedaan in PHP en mysql en ga deze opdracht dus ook hiermee maken.
Gezien het feit dat de opdrachtgever de menu items zelf wil aanpassen, heb ik een backoffice gemaakt waarin ze eenvoudig de items van het menu kan wijzigen en de volgorde aanpassen (Het betreft ca 4 a 5 hoofdgroepen, en per hoofdgroep tussen de 1 en 15 subgroepen)
Nu heb ik het script zo, dat hij bij het laden van het menu, een query doet aan de db, en zodanig het menu laadt. (Elke reload van pagina = dus opnieuw de query uitvoeren).
Nu zal dat voor de 500 bezoekers max per week niet zo'n heel probleem zijn, maar ik wil wel graag weten of ik niet beter een andere optie kan kiezen nu al, of als de website in bekendheid toeneemt.

Ik heb zelf de volgende alternatieven bedacht:
Na een wijziging in de backoffice deze waarden naar file schrijven en deze includen (als array). (Schrijven zal heel af en toe gebeuren, niet vaak)
Waarden eenmalig allemaal laden in hoofdpagina en bijhouden als array gedurende de hele site als globale variabelen.

Wat is de beste optie (ook met oog op eventueel meer dataverkeer in toekomst)?
En misschien (vast wel) hebben jullie betere opties?

[Cartman!]

Zoek eens op "caching"

[Janoz]

soepah schreef op dinsdag 20 oktober 2009 @ 14:08:
Waarden eenmalig allemaal laden in hoofdpagina en bijhouden als array gedurende de hele site als globale variabelen.

Kan niet in php. Er is geen application scope (tenzij je gaat kloten met memcache) dus het zal nog steeds elk request ingeladen worden.

Het wegschrijven is echter wel een goede optie (waarom dan trouwens als een array? Je zou ook gewoon de te genereren html weg kunnen schrijven als je toch al bezig bent).

Ik vraag me echter af of het uberhaupt nut heeft. Ook als de winkel super hard gaat lopen zal deze kleine query nauwelijks uit gaan maken op de perfomance. De database verbinding heb je toch al nodig dus dat maakt niet uit. De query is simpel en de dataset is klein dus dat is het probleem ook niet.

[soepah]

Janoz schreef op dinsdag 20 oktober 2009 @ 14:29:
[...]
Ik vraag me echter af of het uberhaupt nut heeft. Ook als de winkel super hard gaat lopen zal deze kleine query nauwelijks uit gaan maken op de perfomance. De database verbinding heb je toch al nodig dus dat maakt niet uit. De query is simpel en de dataset is klein dus dat is het probleem ook niet.

Oke, dus perfomance mbt tot 1 of 2 queryies die elke pageview worden aangeroepen maakt niet veel uit? dan laat ik het voorlopig zo, mocht hij traag worden of mensen die klagen kan ik altijd nog eens gaan kijken
Bedankt voor je antwoord iig Janoz

[flashin]

Dit en dataverkeer is totaal niet interessant bij deze orde van grootte. 500 bezoekers per week is niks!

Denk gewoon goed na over je databasemodel en je queries, leg goede indexes aan en dan ben je in principe klaar. Ik zie echt geen reden om nu onzinnige cache of memcache mechanismen te gaan gebruiken terwijl je die totaal niet nodig zult hebben.

[Ram0n]

Inderdaad, dat wordt allemaal pas interessant als je elke dag duizenden bezoekers hebt. Niettemin zijn er wel enkele simpele dingen die je kan doen: bijvoorbeeld gebruik maken van een template-systeem als Smarty (die al wat caching voor je doet) en iets als ADOdb om queries uit te voeren. Daarin kan je queries laten cachen, dat lijkt te zijn wat je wilt, al zou ik dat nu nog even afraden. Dat zijn enkele zaken die hoe dan ook handig zijn om te gebruiken, buiten de mogelijkheden tot caching zal het je ook op andere punten tijd besparen.

[ Voor 9% gewijzigd door Ram0n op 20-10-2009 14:53 ]

[MBV]

Je zal niet de eerste zijn die erachter komt dat zijn geniale caching-mechanisme uiteindelijk langzamer is dan 'gewoon' SQL uitvoeren Vaak is de caching-instellingen van MySQL goed zetten (o.a. query-cache, en zorgen dat de query karakter-voor-karakter gelijk is voor alle pagina's) veel effectiever: stiekem werkt MySQL vaak veel beter dan een gewoon filesystem, vandaar dat we het als database gebruiken

En 500 bezoekers is inderdaad helemaal niks. Het wordt pas kritisch zodra het eerste request nog aan het laden is terwijl de tweede binnenkomt. Als al je bezoekers in 1 uur langskomen, dan heb je alsnog 7 sec om de hele pagina te genereren. Geen punt dus

[AtleX]

Janoz schreef op dinsdag 20 oktober 2009 @ 14:29:
[...]

Kan niet in php. Er is geen application scope (tenzij je gaat kloten met memcache) dus het zal nog steeds elk request ingeladen worden.

PHP noemt variabelen in de request scope ook globale variabelen.

[Janoz]

Lees de reactie waarop ik reageer nog eens. Tenzij de topicstarter het menu een stuk of drie keer op het scherm wil renderen lijkt het me redelijk aannemelijk dat de topicstarter refereerde naar een application scope achtige context.

[AtleX]

Uhm ja, ik had even verkeerd nagedacht.

[cariolive23]

premature optimization is the root of all evil

Ga dus niet "optimaliseren" voordat je een probleem hebt. En zorg er voor dat je weet wélk probleem je nu precies hebt, anders valt er nog steeds niets te optimaliseren.

[Gomez12]

soepah schreef op dinsdag 20 oktober 2009 @ 14:45:
[...]

Oke, dus perfomance mbt tot 1 of 2 queryies die elke pageview worden aangeroepen maakt niet veel uit?

Ja en nee, hangt af van je query's...

Doen je query's er 3 seconden over dan maakt het veel uit, maar dan zou je eerst goed naar je query's moeten kijken...

In principe is FS sneller dan DB, maar het brengt wel vele extra problemen met zich mee.
Ik zou gewoon eerst eens kijken of je query's goed zijn, daarna pas kijken naar caching. En dit is pas als er echt een probleem is ( zodat je weet waar je naar moet kijken ). Gewoon je query's / db goed opbouwen en het zou geen enkel probleem moeten zijn.

[GlowMouse]

flashin schreef op dinsdag 20 oktober 2009 @ 14:48:
Denk gewoon goed na over je databasemodel en je queries, leg goede indexes aan en dan ben je in principe klaar.

Voordat je weet hoe je goede indices aanlegt ben je een week verder.

MBV schreef op dinsdag 20 oktober 2009 @ 14:59:
Je zal niet de eerste zijn die erachter komt dat zijn geniale caching-mechanisme uiteindelijk langzamer is dan 'gewoon' SQL uitvoeren Vaak is de caching-instellingen van MySQL goed zetten (o.a. query-cache, en zorgen dat de query karakter-voor-karakter gelijk is voor alle pagina's)

MySQL's cache is juist erg slecht; alleen InnoDB heeft redelijke caching, en MyISAM alleen voor de keys. Query-cache neem ik niet serieus en de rest doet het OS allemaal. Resultset-caching kun je beter in de applicatie regelen.

[ Voor 4% gewijzigd door GlowMouse op 20-10-2009 20:02 ]

[MBV]

GlowMouse schreef op dinsdag 20 oktober 2009 @ 20:00:
[...]

Voordat je weet hoe je goede indices aanlegt ben je een week verder.

slow-query-log aanzetten, EXPLAIN <query> uitvoeren in PHPMyAdmin, en alles waar 'using filesort' bij staat heeft een index nodig. Gebruik daarvoor de ID's die worden gebruikt in de join. Sim-pel.

[...]

MySQL's cache is juist erg slecht; alleen InnoDB heeft redelijke caching, en MyISAM alleen voor de keys. Query-cache neem ik niet serieus en de rest doet het OS allemaal. Resultset-caching kun je beter in de applicatie regelen.

Als je het goed doet. Waar ik heb gewerkt werd een eigen vorm van caching gebruikt, die de boel alleen maar vertraagde. De oplossing was om alle statische pagina's aan de 'voorkant' te cachen: request afvangen voor index.php werd uitgevoerd en een bestandje teruggeven.

Gomez12 schreef op dinsdag 20 oktober 2009 @ 19:56:

In principe is FS sneller dan DB

In principe juist niet: DBMS-en zijn uitgevonden omdat filesystems ook hun beperkingen kennen. Dat er een aantal gevallen zijn waarbij een FS sneller is dan een DB, doet er niks aan af: ga maar eens een join tussen 2 bestanden op je file-system doen.

[Gomez12]

MBV schreef op woensdag 21 oktober 2009 @ 12:10:
[...]

In principe juist niet: DBMS-en zijn uitgevonden omdat filesystems ook hun beperkingen kennen. Dat er een aantal gevallen zijn waarbij een FS sneller is dan een DB, doet er niks aan af: ga maar eens een join tussen 2 bestanden op je file-system doen.

Qua data serveren is een FS "altijd" sneller dan een DB ( enkele compleet geoptimaliseerde servers na, default staat een DB op een FS, alles wat je in de DB doet zijn dus extra stappen )

Enkel als je dingen binnen een FS wilt doen waar een FS niet voor geschikt is tja...

TS heeft het over elke wijziging statisch wegschrijven naar files, zodat enkel losse files geserveerd worden. Dat is altijd sneller...

Enkel het bijhouden van die losse files is bij een beetje DB / site niet meer te doen ( simpel voorbeeldje, GoT heeft meerdere layouts ( zeg even 3 ), 3 miljoen berichten ( even uit de extreeem losse pols ) als je dus het copyright in de footer wilt veranderen naar 2010, dan moet je eventjes 9 miljoen files genereren ( nog even ervanuit gegaan dat je dan maar 1 pagina per topic hebt, met variabele paginagroottes etc wordt het weer een veelvoud ). Elke usericon wijziging is weer x miljoen files opnieuw genereren... )

[YopY]

Filesystem dingen zou ik alleen doen bij triviale programma's of als de content statisch is en er niet doorheen gezocht moet worden. In dit geval, een gerenderd stuk HTML van in dit geval het menu. Maar dat zijn op zich dingen die je over kunt laten aan (bijvoorbeeld) Smarty, als je die gebruikt.

Mja, om een groot deel van de reacties even samen te vatten: Hoed je voor het Premature Optimization anti-pattern. Ga nu lekker je app ontwikkelen, geen domme dingen doen, dingen niet nodeloos complex maken (pas op voor spaghetti en/of lasagnecode), en ga je pas zorgen maken over performance als je vindt dat je pagina's te langzaam laden, danwel je host gaat janken.

En onthoudt natuurlijk ook dat performance hem meestal in suboptimale databasequeries zit, met PHP daarna pas. En dat laatste kun je maar tot zover optimaliseren - zorg ervoor dat je geen vreemde sprongen of micro-optimalisaties gaat toepassen, aangezien die in verhouding toch niet zoveel oplossen. (++$i is 10% sneller dan $i++ volgens sommigen, maar 10% van bijna niks is nog steeds bijna niks)

[cariolive23]

MBV schreef op woensdag 21 oktober 2009 @ 12:10:
[...]

slow-query-log aanzetten, EXPLAIN <query> uitvoeren in PHPMyAdmin, en alles waar 'using filesort' bij staat heeft een index nodig. Gebruik daarvoor de ID's die worden gebruikt in de join. Sim-pel.

Inderdaad, zelfs iets té simpel, zo werkt het dus niet.

Indexen kunnen je namelijk ook in de weg zitten, inserts en updates worden langzamer en de queryplanner gebruikt bij andere queries mogelijk de verkeerde indexen waardoor ook die queries langzamer worden. Daarnaast zal een slechte query altijd tot slechte resultaten leiden, ook wanneer je lukraak wat extra indexen gaat aanmaken. Het herschrijven van queries levert vaak al betere performance op, het kiezen van de juiste indexen op de juiste combinatie van kolommen zal de boel dan nog verder versnellen.

Optimaliseren is een vak apart, niet iets wat je even doet aan de hand van wat vage uitkomsten van een enkele EXPLAIN of een overvolle slow-query-log.

[MBV]

Dat weet ik, ik heb er vaak genoeg mee geworsteld. Helaas was een DBA niet mogelijk. Maar voor redelijk eenvoudige databases is het best te doen om indexen te leggen op de velden waarop gezocht wordt, ook zonder extreem veel kennis van optimaliseren. Wat ik voorstel is iets wat in 90% van de gevallen ervoor zorgt dat een query van 5 minuten naar 10 seconden gaat, en in 10% van de gevallen van 10 seconden naar 20. Zodra je die basis-optimalisaties (low-hanging fruit) hebt gehad zal je een expert moeten inschakelen.

[Janoz]

Gomez12 schreef op woensdag 21 oktober 2009 @ 12:55:
[...]

Qua data serveren is een FS "altijd" sneller dan een DB ( enkele compleet geoptimaliseerde servers na, default staat een DB op een FS, alles wat je in de DB doet zijn dus extra stappen )

Je mist zijn punt. Ja, een FS is sneller in het opleveren van x bytes. Een FS zal vaak ook nog wel sneller zijn wanneer je x specifieke bytes op wilt laten lepelen. Maar zodra je een berg bytes nodig hebt waarbij welke bytes je nu eigenlijk moet hebben afhangt van de andere bytes die je opgevraagd hebt, dan is het verhaaltje al lang zo zwart wit niet meer.

Dat een DB ook op een FS staat is eigenlijk nauwlijks een argument. Ik pas in mijn jas. Mijn jas past in mijn tas. Ik zou dus eigenlijk met gemak in mijn tas moeten passen toch?

[cariolive23]

MBV schreef op woensdag 21 oktober 2009 @ 14:05:
Wat ik voorstel is iets wat in 90% van de gevallen ervoor zorgt dat een query van 5 minuten naar 10 seconden gaat, en in 10% van de gevallen van 10 seconden naar 20. Zodra je die basis-optimalisaties (low-hanging fruit) hebt gehad zal je een expert moeten inschakelen.

In 90% van de gevallen duurt een query geen 5 minuten maar hooguit enkele tienden van een seconde. Ga je niet richten op low hanging fruit, dat levert vaak de situatie op dat het low hanging fruit ineens hoog in de boom wordt gehangen en dus een groter probleem wordt. Richt je op die paar queries (niet meer dan 5 stuks) die gruwelijk langzaam zijn én vaak worden gebruikt en ga daar vervolgens alle queries bijzoeken die hier op lijken. Ga vervolgens de queries zo schrijven dat ze nog veel meer op elkaar lijken, dan de complexe queries optimaliseren en indexen aanmaken. Wanneer dit klaar is, zul je zien dat al snel 80% van alle queries ineens veel sneller is geworden.

3 aparte indexen op de kolommen x, y en z kunnen onbruikbaar zijn, één index op de kolommen x, y en z kan langzaam zijn en één index op de kolommen x, z en y kan dé oplossing zijn voor 80% van de queries op één tabel. Komt nog bij dat MySQL de nodige gebreken kent, zeker de oudere versies gaan erg slecht om met indexen.

Low hanging fruit krijg je cadeau wanneer je de grootste problemen aanpakt, daar hoef je geen extra energie in te steken. Helemaal niet omdat je dan regelmatig problemen gaat verplaatsen. Jouw "basis-optimalisaties" kunnen wel eens overbodig werk zijn, dat is zonde van de tijd en energie.

Ps. Nadat je de 5 grootste knelpunten hebt aangepakt, zul je opnieuw moeten testen en benchmarken, alle vorige resultaten zijn waardeloos geworden omdat die met de oude situatie. Automatisch queries loggen en EXPLAIN-en heeft uiteraard de voorkeur, kun je zelf een scriptje voor schrijven.

[MBV]

In 90% van de gevallen die ik heb gezien wordt een performance-probleem op een website (waar nog niks aan geoptimaliseerd is) veroorzaakt door een, of een paar, queries die erg traag zijn. Als er nog niets geoptimaliseerd is (waar ik in dit geval, gezien de TS, vanuit ga) zijn er nog geen idices op tabellen (behalve hopelijk de PK's). Dan kom je de situatie tegen dat een full-table-scan nodig is voor een simpele join, en gaat de performance van meerdere seconden naar 0.01 seconde.
Als je al indices hebt aangelegd op de kolommen waar vaak op gezocht wordt, en daarna nog performance-problemen tegenkomt, dan kom je bij de problemen aan die jij beschrijft.

Stel je voor:

SQL:

SELECT x, y, z
FROM product_table
WHERE ean = ?

Dat is een zoekopdracht op een integer die niet in de primary key zit. Dat gaat heel leuk in de testomgeving, maar zodra je 100.000 artikelen hebt wordt die erg langzaam. Een index op de kolom ean zetten zal, zolang er verder nog geen indices zijn, nooit voor een performanceverslechtering zorgen. En voordat je aan de optimalisaties in de database begint hangt die boom vol met dit soort low hanging fruit.

* MBV moet zich eens niet laten verleiden tot dit soort zinloze discussies . Tuurlijk werkt dit niet om de performance-problemen van een ERP op te lossen, maar we hebben het over de beginsituatie: kleine web-app zonder enige optimalisatie.

[ Voor 9% gewijzigd door MBV op 21-10-2009 17:15 ]