[PHP/MySQL] Serverload verlagen

[Verwijderd]

Hallo,

Ik ben bezig met het leren van PHP.
Begin het al onder de knie te krijgen , maar hoe kan ik nu zorgen dat me serverload laag blijft.
In de artikelen stond het niet en kan het ook niet vinden.

Deze punten weet ik :

- Connect i.p.v Pconnect
- Zo weinig mogelijk query's gebruiken

Denk dat dit topic ook wel handig is voor anderen.
Post a.u.b manieren die ook kunnen worden gebruikt.

Is mysql_close ook niet zo'n mogelijkheid?

[Verwijderd]

Caching, heel erg belangrijk... Ik werk ook bij een internetsites met 1.5m views per maand en veel databasequeries, zonder caching werkte het echt niet.

[NMe]

De eerste hit als ik ga [google=optimize php code]: http://phplens.com/lens/p...imizing-debugging-php.php

[crisp]

PHP optimalization is doorgaans van minder groot belang aangezien over het algemeen 90% van je executie-tijd in MySQL queries zit.
Staar je ook niet blind op mini-optimalisaties in PHP code; dat is meestal de moeite niet.

[eghie]

Verwijderd schreef op maandag 28 november 2005 @ 18:10:
Caching, heel erg belangrijk... Ik werk ook bij een internetsites met 1.5m views per maand en veel databasequeries, zonder caching werkte het echt niet.

Ik ga met Boland mee. Caching is een van de meest belangrijke dingen, bij een snelle website. Scheelt je ook een zooi load op de server.

Nu heb je alleen verschillende niveau's van cachen. DMBS-Website-Proxy (eventueel)-Client.

Het meeste load gaat zitten in database query's, zoals ook al gezegd is door crisp. Om MySQL query's te optimaliseren kun je EXPLAIN statement gebruiken, om trage stukken uit je query te herkennen. Met vele DBMSen kun je ook je query's cachen. Stored Procedures worden geloof ik gecached. Ook parametrized query's worden gecached. Als je die dingen op de goede manier gaat gebruiken, scheelt het je al een hoop load en snelheid aan de DBMS kant.

Nu kun je met PHP ook al dingen doen om je data te cachen. Probeer bijvoorbeeld een systeem te maken dat bijvoorbeeld de data van de DB cached in het geheugen van de server. Dit kan je een hoop nutteloze database calls schelen. Bijvoorbeeld hier op tweakers.net. De frontpage wordt hier gecached. Er wordt zelfs een statische pagina van gemaakt, om de zoveel tijd (tenminste heb ik me laten vertellen). Nu kun je verschillende delen, die weinig veranderingen ondergaan, van je site cachen.

Nu zou ik, net zoals crisp ook al zei, niet je PHP code gaan optimaliseren en zo leesbaarheid inleveren. Dit verschil is te weinig om echt wat uit te maken.

Nu kun je ook wel redelijk wat met HTTP headers doen, om te zorgen dat de browser en eventuele proxy's ook dingen gaan cachen van je site. Lees Caching Tutorial for Web Authors and Webmasters voor meer informatie hierover.

Ook kun je met manier van implementatie al zorgen dat dingen worden gecached. Als je bijvoorbeeld Javascript gebruikt en die gebruik je in meerdere pagina's, stop het in een .JS bestand. Deze bestanden worden namelijk ook gecached. Je CSS bijvoorbeeld, stop die ook in een extern bestand. Dit bevorderd ook de onderhoudbaarheid, maar ook de load op de server.

Nu heb je ook nog die compressie/encryptie programma's die je HTML,JS,CSS bestanden kleiner maken. Dit kan ook wel helpen, maar ik vind ze maar bout. Naar mijn idee helpen die dingen ook vrij weinig, maar heb hier weinig ervaring mee, dus ook niet echt een goede kijk op wat betreft de serverload. Als iemand weet wat en hoe het scheelt op de serverload, aarzel dan niet om te antwoorden.

Nu is dat, tegenwoordig populaire, AJAX ook een leuke middel om voor de gebruiker al in ieder geval je site sneller te laten lijken. Ik weet niet hoe je dit in combinatie met caching mooi kunt oplossing, gezien ik niet precies weet hoe browsers de boel cachen. Maar nu kun je met AJAX icm andere client-side scripting technieken veel doen in je webpagina, zonder dat je al te veel vraagt van de server. Als je het goed gebruikt, heb je haast niks geen postbacks met de server.

[crisp]

eghie schreef op maandag 28 november 2005 @ 22:34:
[...]
Nu heb je ook nog die compressie/encryptie programma's die je HTML,JS,CSS bestanden kleiner maken. Dit kan ook wel helpen, maar ik vind ze maar bout. Naar mijn idee helpen die dingen ook vrij weinig, maar heb hier weinig ervaring mee, dus ook niet echt een goede kijk op wat betreft de serverload. Als iemand weet wat en hoe het scheelt op de serverload, aarzel dan niet om te antwoorden.

Compleet nutteloos als je al HTTP compressie gebruikt. HTTP compressie zelf zorgt wel voor een iets hogere load, maar je wint dik op bandbreedte (en de client op laadtijd).

Nu is dat, tegenwoordig populaire, AJAX ook een leuke middel om voor de gebruiker al in ieder geval je site sneller te laten lijken. Ik weet niet hoe je dit in combinatie met caching mooi kunt oplossing, gezien ik niet precies weet hoe browsers de boel cachen. Maar nu kun je met AJAX icm andere client-side scripting technieken veel doen in je webpagina, zonder dat je al te veel vraagt van de server. Als je het goed gebruikt, heb je haast niks geen postbacks met de server.

Ajax is bedoelt om de user-experience te verbeteren (geen postbacks, bijna real-time deskapp-like feel), maar in het beste geval levert het je juist meer requests op aan de serverkant.

Caching van Ajax-responses is best goed mogelijk, maar je moet dan zelf de complete header-afhandeling doen in je serverside script en 304's genereren indien de client aangeeft een gecachede versie te hebben.

[Brakkie]

Zend optimizer, Alternative php cache of eAccelerator kunnen ook een hoop voor je doen zonder dat je zelf veel moeite hoeft te doen. Dit zijn extensies voor php die simpel gezegd je php code cachen. Dit kan veel snelheidswinst opleveren.

[flashin]

Nu kun je met PHP ook al dingen doen om je data te cachen. Probeer bijvoorbeeld een systeem te maken dat bijvoorbeeld de data van de DB cached in het geheugen van de server. Dit kan je een hoop nutteloze database calls schelen. Bijvoorbeeld hier op tweakers.net. De frontpage wordt hier gecached. Er wordt zelfs een statische pagina van gemaakt, om de zoveel tijd (tenminste heb ik me laten vertellen). Nu kun je verschillende delen, die weinig veranderingen ondergaan, van je site cachen.

Check anders eens de source van wat opensource weblog software. Die hebben vaak ook een "generate output" functionaliteit waarmee er vanaf een DB of XML statische content gegenereerd wordt.

[kmf]

mijn grote truuk is om weinig veranderende data in een grote associative array te stoppen en deze serialzed in de database te stoppen.
Dit gebruik ik bv voor de settings van de site, de group permissions, categorieen/albums, etc etc.
Bespaart al snel een query of 4.

Al naar gelang de site kan ik ervoor kiezen om deze array ook in een bestand te stoppen om later uit te lezen en alleen bij updates opnieuw te genereren.

Om je server load zonder programmeertruukjes omlaag te brengen zijn nog andere truuks. Maar die passen niet echt in dit forum, dus laat ik ze maar achterwege.

[crisp]

Brakkie schreef op maandag 28 november 2005 @ 22:45:
Zend optimizer, Alternative php cache of eAccelerator kunnen ook een hoop voor je doen zonder dat je zelf veel moeite hoeft te doen. Dit zijn extensies voor php die simpel gezegd je php code cachen. Dit kan veel snelheidswinst opleveren.

Ja, tot wel 50% op 10% van je totale load, want nogmaals: 90% zit 'm in de database
Query-caching en veelgevraagde, doch redelijk statische, pagina's voor-fabriceren ipv on-request scheelt je 80% van die 90%

[Brakkie]

crisp schreef op maandag 28 november 2005 @ 22:50:
[...]

Ja, tot wel 50% op 10% van je totale load, want nogmaals: 90% zit 'm in de database
Query-caching en veelgevraagde, doch redelijk statische, pagina's voor-fabriceren ipv on-request scheelt je 80% van die 90%

Optimalisatie die je praktisch cadeau krijgt zou ik niet laten liggen. Ik heb laatst nog gezien dat het gebruikt van APC een enorm verschil kan maken bij het acceptabel houden van de load op een druk bezochte site. De code hiervan was redelijk amateuristisch, gemaakt door een beginnende phpér, en ook redelijk omvangrijk. Het gebruik van APC betekende op veel plaatsen een halvering van de parse tijd. Uiteraard is er op nog veel effectievere manieren te optimaliseren maar voorlopig kan deze site het grote aantal bezoekers wel veel beter aan. (zo'n 500 tegelijkertijd op hoogte punten) Caching per content blokje op de site gaan we nu rustig verder aan werken maar door de opcode cache kunnen ze beter vooruit, zeker niet uit te vlakken naar mijn mening dus,

[ Voor 15% gewijzigd door Brakkie op 29-11-2005 00:13 ]

[kmf]

crisp schreef op maandag 28 november 2005 @ 22:50:
[...]

Ja, tot wel 50% op 10% van je totale load, want nogmaals: 90% zit 'm in de database
Query-caching en veelgevraagde, doch redelijk statische, pagina's voor-fabriceren ipv on-request scheelt je 80% van die 90%

In de praktijk heeft het gebruik van eaccelorator mijn server load van gemiddeld 10 naar 1-2 teruggebracht en terwijl mijn sites toch echt db-driven zijn.

[crisp]

Brakkie: het is zeker wel 'snelle winst' ja; wij gebruiken hier bij Tweakers overigens eAccelerator - dat scheelt voor sommige stukken code ook wel aardig wat, maar de meeste echte optimalisaties zitten 'm over het algemeen toch in queries die voor verbetering vatbaar zijn (hetzij dmv indexen, hetzij door het uit elkaar trekken van complexe queries of juist door het samenvoegen van queries).

[Hydra]

Als je bezig bent met het leren van PHP is optimalizatie niet iets waar je je zorgen over moet maken. Je moet je alleen zorgen maken over stomme dingen die te vermijden zijn. Je eerste probeersels zullen over 't algemeen geen sites zijn met miljoenen users per maand, dus zo'n groot issue is het niet.

[Verwijderd]

Of dingen die je niet perse in de database nodig hebt ook niet in de database stoppen. Het is beetje zinloos om statics bij elke hit uit de database te trekken. Een simpele include van een file als

PHP:

$param1  = true;
$param12 = "hutseflutser";

Kan aanzienlijk schelen. Wat ook boeiend kan zijn, is idd de caching van query resultaten.
Check het adodb framework maar eens, voor een simpel overzichtje van gegevens uit exact. Vanaf een sql2000 server via 100Mbit naar mijn linux omgeving scheelt het slim caching van query resultaten soms seconden op 1 overzicht. (veel joins, innerjoins and inline SQL geleuter). In adodb kun je per select query aangeven hoe lang deze in de cache mag blijven staan. Het cache systeem werkt in file mode.

Ik ga er namelijk nog steeds vanuit dat een include sneller is dan een ingewikkelde query.

[BierPul]

Verwijderd schreef op maandag 28 november 2005 @ 17:59:
- Zo weinig mogelijk query's gebruiken

Daar ben ik het niet helemaal mee eens , ik zie liever 5 goeie queries dan 1 slechte JOIN ofzo

[Verwijderd]

Kwa caching heb je in Java bijvoorbeeld OSCache. Deze kun je op het niveau van taglibs heel makkelijk gebruiken om gehele of gedeeltes van je JSP pagina te cachen. Aan de cache kun je dan een event handler hanger zodat bij een update van de data een event ge-trigered wordt die de cache invalideerd.

Getimed kan echter ook en is vaak veel makkelijker en bijna net zo goed (zoals bv de FP van tweakers).

Mooie examples:

Basic voorbeeld:

Java:

<cache:cache>
      ... some jsp content ...
</cache:cache>

This will cache the content with a programmatic key, expiring it every morning at 2am. It will also refresh if the variable needRefresh
is true.

Java:

<cache:cache key="<%= product.getId() %>" cron="0 2 * * *" refresh="<%= needRefresh %>">
      ... some jsp content ...
</cache:cache>

bron: http://www.opensymphony.com/oscache/wiki/JSP%20Tags.html

De details voor een PHP oplossing zullen natuurlijk verschillen, maar ik neem aan dat er iets vergelijkbaars ook wel voor PHP te krijgen. Het principe zal wel hetzelfde zijn:

Je zet de tag om een stuk content heen wat je wilt cachen (kan ook de hele page zijn) en hangt er wat condities aan met betrekking tot geldigheid en refreshing.

Ook heel handig is dat je met een cached solution pagina's kunt blijven serveren terwijl je DB er (even) uitlegt.

[ Voor 4% gewijzigd door Verwijderd op 29-11-2005 23:33 ]

[PhoeniX-]

Aangezien het meeste te winnen valt bij database queries: denk je db model goed uit en maak indexes op je tabellen waar mogelijk! Dit heeft in enkele grote sites bij mij aanzienlijke tijdswinst opgeleverd.

[Verwijderd]

crisp schreef op maandag 28 november 2005 @ 22:44:
Caching van Ajax-responses is best goed mogelijk, maar je moet dan zelf de complete header-afhandeling doen in je serverside script en 304's genereren indien de client aangeeft een gecachede versie te hebben.

Niet helemaal mee eens. Zoals hierboven al werd aangegeven gaat het meeste tijd zitten in de communicatie naar en de verwerking op de database-server. Wat je dus in principe kunt doen is bij het binnenkomen van een request (via Ajax of niet, voor de server irrelevant), kijken of de betreffende pagina gecached is en zonodig deze terug geven. Er vindt dan nog wel enige PHP-parsing plaats, maar je hebt niet meer te maken met de database-handelingen.