Onderwerp: Website caching, vanaf hoeveel hits en hoe duur?

Hallo allen,

Aangezien wij druk bezig zijn met een nieuwe website waar wij vrij snel 5.000 unieke bezoekers per dag hopen te mogen ontvangen ben ik me gaan verdiepen in website caching. Het is natuurlijk iets dat veel gebruikt wordt bij grote sites en mijn twee vragen zijn eigenlijk vrij simpel:

* Vanaf hoeveel connecties per dag/maand wordt caching echt een must?

* Hoeveel moet het ongeveer gaan kosten om een al bestaande website om te bouwen zodat de site gecached kan worden of is dit sterk verschillend per site?

alvast bedankt voor de antwoorden.

Er zijn meerdere mogelijkheden, en de vraag bij hoeveel hits het interessant wordt is moeilijk te beantwoorden. Het ligt aan de complexiteit - en vooral netheid - van je code en query's. Bij PHP kun je standaard modules installeren zoals Eaccellerator. Vaak krijg je veel verkeer op de Index die veel traffic doet en wil je die statisch maken (cron: php -q index.php > index.html) en zo zijn er legio voorbeelden te noemen. Ook kun je een proxy inzetten met bijvoorbeeld squid.
Belangrijk is dat alles wat niet juist geprogrammeerd is, nooit ingehaald kan worden met accelleratie. Let daarbij vooral op het MySQL werk. In de praktijk zie ik wel eens de meest onmogelijke query's (SELECT * FROM`tabel`) waarna vervolgens php wordt losgelaten voor het rekenwerk. Dit is natuurlijk de ergste vorm van het verspillen van systeemresources.

De vragen zijn niet te beantwoorden zonder de site gezien te hebben, evenzo geldt voor de broncode. Ook niet zonder te weten welke scripttaal er gebruikt is. Maar om je toch een antwoord te geven; voor het installeren van bijvoorbeeld Eaccellerator vraag ik de prijs van 1 ticket; 35,-.
Wil je dat een pro de query's naloopt kom je op 85,- per uur (gecertificeerde DBA).

Bedankt voor het antwoord en ik begrijp dat het een behoorlijk algemene vraag is zonder al te veel gegevens dus ik waardeer je poging om het e.e.a. duidelijk te maken

De query's zullen niet 100% geoptimaliseerd zijn maar er wordt wel gewerkt met fatsoenlijke query's die de selectie beperken tot wat nodig is en de nodige JOIN's e.d. uitvoeren om zoveel mogelijk met 1 query te bemachtigen.

Ik denk dus ook dat het nog meer optimaliseren van de queries wel mogelijk zal zijn maar in beperkte maten. Vergeleken met de kosten (85,- p/u) voor deze optimalisatie t.o.v. de kosten voor het installeren van een cache systeem zal dit laatste dus vele malen meer winst opleveren per euro.

Voorlopig wordt er overigens nog druk gewerkt aan de site maar ik neem dit advies zeker mee en de kans dat er een vorm van caching geïmplementeerd wordt op een gegeven moment is dus ook behoorlijk groot.

Oorspronkelijk geplaatst door J.Mertz

Ik denk dus ook dat het nog meer optimaliseren van de queries wel mogelijk zal zijn maar in beperkte maten. Vergeleken met de kosten (85,- p/u) voor deze optimalisatie t.o.v. de kosten voor het installeren van een cache systeem zal dit laatste dus vele malen meer winst opleveren per euro.

Het is niet zo dat je met het ene het andere voorkomt natuurlijk. Als je hardware het moeilijk krijgt met de website zal je eerst de meest goedkope oplossing doen, gebruik van acceleratie. Als dat na een tijdje ook niet meer voldoende helpt kun je je code laten controleren of je moet je hardware uitbreiden.

Uiteraard moet de code zo goed mogelijk in elkaar zitten om hardware kosten te voorkomen. Webservers zijn nog wel makkelijk te clusteren en te load balancen, maar als je SQL servers het na een tijdje niet meer trekken dan krijg je grotere problemen. Dan is het optimaliseren van de code misschien toch goedkoper.

Nog een keer het belangrijkste stukje uit mijn tekst:

Oorspronkelijk geplaatst door Randy

Belangrijk is dat alles wat niet juist geprogrammeerd is, nooit ingehaald kan worden met accelleratie. Let daarbij vooral op het MySQL werk.

maar je kunt inderdaad beginnen met een accelleratiemodule. Een DBA hoeft trouwens niet alle Query's opnieuw op te bouwen, maar kan deze zo even nalopen en de grote fouten eruit halen. Dan is hij of zij ook geen dagen bezig, maar enkele uren. Een goede DBA kost nu eenmaal geld. Ikzelf laat dit ook altijd doen. Mijn specialisatie ligt specifiek op beheer, niet op databases.

Mocht je nog aan het programmeren zijn kun je nu toch ook al delen van je site laten cachen? Het is nu nog makkelijk in te bouwen. Laat bijv een eventueel nieuwssysteem gewoon de lijsten cachen en werk ze pas bij op het moment dat je een nieuw nieuwsbericht toevoegt. Dit soort dingen zijn heel makkelijk te bouwen en kunnen je toch al een aardige besparing op het gebied van aantallen query's opleveren.

Mocht je echt hard gaan groeien en veel bezoekers verwachten dan is er maar 1 echt serieuze partij imho om zaken mee te doen als het om caching enz gaat: http://www.akamai.com/

Oorspronkelijk geplaatst door mdf

Mocht je echt hard gaan groeien en veel bezoekers verwachten dan is er maar 1 echt serieuze partij imho om zaken mee te doen als het om caching enz gaat: http://www.akamai.com/

akamai is een prima partij, maar is alleen echt interessant als je website wereldwijd veel bezoekers krijgt. Als je website vrijwel alleen bezoekers uit Nederland kent is het kosten technisch veel slimmer om een eigen proxy neer te zetten. Akamai is dan ook meer een CDN dan alleen 'een cache partij'.

Overigens beheer ik een website die voorheen ook met Akamai werkte, maar sinds we die er tussenuit hebben gehaald en hebben vervangen met mod_cache en caching in de (JAVA) applicatie zelf is de website 20% sneller.

Mocht je nog vragen hebben kun je me altijd een berichtje sturen.

Oorspronkelijk geplaatst door J.Mertz

De query's zullen niet 100% geoptimaliseerd zijn maar er wordt wel gewerkt met fatsoenlijke query's die de selectie beperken tot wat nodig is en de nodige JOIN's e.d. uitvoeren om zoveel mogelijk met 1 query te bemachtigen.

Pardon my french, maar dat haalt geen zak uit. Iedereen die iets van systeemtuning kent, zal je zeggen dat hij liever 1000 queries heeft die juiste indexen enz gebruiken dan 1 query die dat niet doet (en misschien niet cachebaar is omdat pearDB gebruikt wordt met mysql, k zeg maar iets).

Ik denk dus ook dat het nog meer optimaliseren van de queries wel mogelijk zal zijn maar in beperkte maten. Vergeleken met de kosten (85,- p/u) voor deze optimalisatie t.o.v. de kosten voor het installeren van een cache systeem zal dit laatste dus vele malen meer winst opleveren per euro.

Foute mentaliteit en bovendien in 9 gevallen op 10 onjuist.

Je volgorde is eigenlijk deze:

• App afwerken / launchen in betatest
• INDEX-en leggen op je database en je queries verbeteren en je db-cache gebruiken
• filesystem en/of object caching implementeren
• *profiling en de meest tijd-rovende functies optimaliseren

Terug naar je caching: je wil zo veel mogelijk db-caching (en zorg dat die gebruikt wordt!!!. Daarnaast wil je idealiter static-file caching. Kijk ook wat je kan doen met mod_expire enz.

Als front-end engineer houd ik me naast rendertijd ook bezig met caching, maar dan vooral voor terugkomende bezoekers. Het effect van een paar goede Apache instellingen is al enorm, zeker als de bezoekers vaak terugkomen (mod_expires, ETags). Met de juiste instellingen is het mogelijk om de site goed in de proxy caches van ISPs terecht te laten komen, waardoor het al flink versnelt.
Als je het geld hebt, kan je inderdaad voor een CDN gaan.