[PHP/MySQL] Site versnellen *

[eborn]

Hoe kun je allemaal een site versnellen die op PHP/MySQL draait? Laatst werd mij dat namelijk gevraagd. Het ging in dat geval om een site met tabellen van ongeveer 500.000 records. Zelf kwam ik al op wat ideeen, maar jullie kunnen vast nog wel hints en advies geven?

1. Database en/of website opsplitsen over verschillende servers (kost je natuurlijk wel weer een extra server)
2. Betere indexering van tabellen
3. Simpelere queries, waar mogelijk

Zijn er nog dingen die ik over het hoofd zie? En voor de mensen die ervaring hebben met zulk soort problemen: wat raden jullie aan?

[HGM]

Ik denk dat caching toch ook een belangrijk aspect zou kunnen zijn. Is natuurlijk nogal afhankelijk van het soort website.

[eborn]

Wat bedoel je precies met caching? Het cachen van database gegevens o.i.d. ?

[Nielsz]

Op zaterdag 02 februari 2002 20:11 schreef eborn het volgende:
Wat bedoel je precies met caching? Het cachen van database gegevens o.i.d. ?

Je kan natuurlijk voordat je een topiclist oid opvraagt, een query doen om te kijken of er wel een reply is geplaatst, en dan een header 'nothing changed' terug sturen if not

[eborn]

Het gaat (om terug te komen op het voorbeeld) om een site met rubrieken en artikelen waar elk artikel bij een rubriek hoort. Dit moet dus met een WHERE-statement in de query opgelost worden, dus ik denk dat je dat niet veel kunt versnellen, toch?

[ikke_]

prepared statements gebruiken:
where id=? and name=?

dan de ? invullen, zo kan de database 't optimaliseren. Maar of mysql daar iets mee doet weet ik niet.
Indexeren is natuurlijk nooit weg, table scans kunnen 1000x langzamer zijn dan geindexeerde

[ACM]

Op zaterdag 02 februari 2002 20:55 schreef ikke_ het volgende:
dan de ? invullen, zo kan de database 't optimaliseren. Maar of mysql daar iets mee doet weet ik niet.
Indexeren is natuurlijk nooit weg, table scans kunnen 1000x langzamer zijn dan geindexeerde

volgens mij kan mysql het "wel", maar niet met de drivers zoals gebruikt in php

Oracle kan het ook niet zo mooi( als in perl) in php

Andere dingen om over na te denken:
Als de page niet veranderd is, zorg dan dat ie nog bij de browser gecached is. Als de page zelden veranderd nadat ie eenmaal gegenereerd is, zorg dan dat je static html genereerd en dat door de client laat bekijken.

[eborn]

De machine waar het geheel op draait is trouwens een dual-proc met 1 GB geheugen. Hij swapt niet, dus dat brengt geen extra vertragingen met zich mee.

[Anders]

Is static database publishing een optie? Zie bv. http://www.applinet.nl/artikelen/static_database_publishing.html voor een uitleg

/Edit: ik zie dat bovenstaande url commerciëler is dan dat ik het me herinner. Ik heb met het bedrijf niks van doen, voor de duidelijkheid.

[ACM]

Op maandag 04 februari 2002 09:13 schreef eborn het volgende:
Hij swapt niet, dus dat brengt geen extra vertragingen met zich mee.

Sinds wanneer levert dat vertraging?

Als je 2GB aan geheugen nodig hebt (hoe dan ook) wees dan maar erg blij dat ie dat ene GB uit de swap haalt, want over het algemeen blijven je apps dan iig draaien

[eborn]

Maar als MySQL nou maar 1 GB 'nodig' heeft, maar toch nog 1 GB gaat swappen omdat hij het handig vind om iets meer geheugen te gebruiken? Is het dan niet beter dat hij wacht even totdat hij weer genoeg intern geheugen vrij heeft, i.p.v. te gaan swappen?

[Verwijderd]

Een site versnellen is te algemeen om iets mee te kunnen.

Zoek de knelpunten op (bepaalde pagina's zijn te langzaam, hele site te langzaam, te weinig gebruikers kunnen tegelijk werken, er worden te veel resources gebruikt, etc), en ga vanaf daar verder zoeken. Meet realistisch gebruik, zodat je deze situatie kunt gaan simuleren bij het ontwikkelen van een oplossing.

Denk in het algemeen eens aan de volgende zaken:

1) caching: Gegevens die niet vaak veranderen hoeven niet altijd ge-update te worden. Sowieso hoeven gegevens niet altijd op 'pull' basis ververst te worden.

Als er weinig veranderingen zijn, maar die moeten wel altijd direkt doorgevoerd worden, denk dan aan het 'push' updaten van gegevens, d.w.z. dat een nieuwe set gegevens wordt gegenereerd die weer up-to-date is.

Cacheing kan op verschillende nivo's gebeuren, bijv. pagina's of queries.

2) database indexering: de juiste indexen kunnen HEEL VEEL helpen. Lees eens het stukje wat daarover staat in de FAQ (van mijn hand, BTW )

3) database indeling: soms kan het nuttig zijn om je database structuur om te gooien omwille van efficiency. Denk dan aan redundante data, zuiniger data types gebruiken, tabellen splitsen (current en historic tabellen voor een entiteit bijv.)

4) resource gebruik: soms wordt ontzettend onhandig gebruik gemaakt van resources.

Zo wordt er vaak voor iedere pagina aan het begin een connectie geopend, en aan het eind weer gesloten, waardoor er bij veel gebruikers ook veel connecties openstaan, terwijl ze lang niet allemaal tegelijk nodig zijn. Maak gebruik van connection pooling en dergelijke, hou een connectie zo kort mogelijk vast, en een applicatie wordt veel schaalbaarder.

5) services verdelen over meerdere servers : dit is zeker geen magische oplossing, want dit brengt heel vaak zware gevolgen met zich mee, waardoor sommige applicaties zelf langzamer worden.

Als je dit wil doen, moet je echt in je architectuur rekening houden hiermee, want anders ga je vreselijk op je gezicht.

6) query tuning: heel vaal kunnen queries efficienter. Stored procedures zijn vaak sneller, maar er zijn nog zat andere zaken die ook vaak anders kunnen en leiden tot een snellere query

7) code tuning: maak je gebruik van (te) veel includes? heb je veel globale variables? pring je niet op tijd uit je loops? haal je teveel records op? etc.

server tuning: hier valt vaak nog best wel veel te verdienen. Zijn je webserver processen te klein of te groot?? zijn er te veel of te weinig? is je rollback space van je db te groot? swapt je machine teveel? kan je backup op een rustiger tijdstip? etc, etc

HTH

[GiLuX]

waar je mee kan beginnen is de database gewoon minder vaak aanspreken.

bepaalde data die wel elke beschikbaar moet zijn maar weinig veranderd(user preferences/info oid),
meteen de eerste keer uit de database trekken en in een object zetten en dat object in sessie zetten.

elke keer dat je het nodig hebt trek je uit je sessie object (gaat ook nog eens veel sneller).

zolang dat object niet te groot is voor het aantal users/ interne geheugen kan dit bakken met database queries schelen.

doe eens een test en kijk hoe je vaste geheugen zich houdt.

[ACM]

Op maandag 04 februari 2002 14:38 schreef eborn het volgende:
Maar als MySQL nou maar 1 GB 'nodig' heeft, maar toch nog 1 GB gaat swappen omdat hij het handig vind om iets meer geheugen te gebruiken? Is het dan niet beter dat hij wacht even totdat hij weer genoeg intern geheugen vrij heeft, i.p.v. te gaan swappen?

Nee, dan zal het eerder crashen dan beter gaan

Op dinsdag 05 februari 2002 03:12 schreef GiLuX het volgende:
bepaalde data die wel elke beschikbaar moet zijn maar weinig veranderd(user preferences/info oid),
meteen de eerste keer uit de database trekken en in een object zetten en dat object in sessie zetten.

Hoeft niet eens perse een object te zijn, maar wat doe je als iemand de sessie data in de database wil opslaan?

Bijv omdat het een multiwebserver oplossing moet kunnen gaan worden.

[HenkS]

he hallo,

ik heb eens in de 'faq' gekeken naar 'database indexing', er staat een punt bij:
- bedenk dat je je indexen altijd kunt laten tunen....

ehmmm hoe doe je dat??? (mysql dus)

[Verwijderd]

Op dinsdag 05 februari 2002 09:23 schreef HenkS het volgende:
he hallo,

ik heb eens in de 'faq' gekeken naar 'database indexing', er staat een punt bij:
- bedenk dat je je indexen altijd kunt laten tunen....

ehmmm hoe doe je dat??? (mysql dus)

Uhm ... bijna!

"Dyslectics of the word, untie!"

6) bedenk dat je altijd je indexen later kan tunen als je ziet waar de werkelijke bottlenecks bij gebruik zijn

Enjoy

[HenkS]

is nog vroeg zullen we dan maar zeggen

maar dus gewoon maar uitproberen als db groter wordt....

sla nu ook de zoektijd op in de db, dus dan kan ik wel zien of er verbeteringen optreden

[Martijn02]

Het maken van indexen kan enorm schelen, waar je een index maakt is een beetje een gevoel. Het scheelt hoevaak de tabel ge-update wordt en hoevaak hij uitgelezen wordt.

ik denk dat je er voor kan zorgen dat he bij het opvragen van een gewone pagina geen query's doet die niet met een index afkunnen. (ander indexen bijmaken) alleen als je dieper in de site komt (search, listings enzo) dan kom je query's tegen die geen indexen gebruiken

Verder gebruik ik ook een methode voor caching. De menustuctuur van m'n site staat bijvoorbeeld ook in de database, maar die wordt voor iedere pageview helemaal opgevraagd. (SELECT * FROM Menu ORDER BY 'parentID', 'order') Is dus best een zinloze query, omdat hij altijd hetzelfde resultaat geeft, en er niet veel wijzigt in de database. Maar toch staat het menu zo in de database omdat het handig is om wijzigingen aan te brengen (pagina's erbij hangen) in de backoffice.

Nu wil ik het zo doen dat het resultaat gecached wordt iedere keer als ik ik iets wijzig in de tabel Menu. Nou heb ik 2 manieren, en wil ik weten wat sneller is... ik gebruik het ding als een grote array, dus wat ik kan doen is het resultaat en de array stoppen, en die serializen en in een filetje schrijven. Als ik dan het menu nodig heb lees ik het filetje in, en unserialize ik het weer. Een andere manier die ik in gedachten heb is de array door een script in een php file laten schrijven dus iets als

PHP:

<?
$menu = array ( 
    array ( 'ID' => 1, 'name' => 'test', 'parentID' => 0),
    array ( 'ID' => 2, 'name' => 'test1', 'parentID' => 1),
    array ( 'ID' => 3, 'name' => 'test2', 'parentID' => 1)
);
?>

en die file includen... Maar nu is de vraag... welke van de 2 is sneller? Bij het serializen moet de data unserialized worden, maar bij het includen moet de code geintrepeteerd en geparsed worden enzo... Wat is sneller?

Mensen die hier het antwoord op weten? of wordt het een benchmark?


_{tabelstructuur 'Menu'
=====================
ID
parentID
order
name
URL
active
visible
default
pageID}