Performance loadbalanced webservers

[TheNephilim]

Hey,

Samen met 2 jongens beheer ik een website. Deze website heeft dagelijks 8000+ unieke bezoekers die ook inloggen.

-----Informatie------

Sinds een poosje ziet opzet server opzet er zo uit:
- 1 loadbalancer (Loadmaster 2500)
- 4x webservers (Opteron 165 (2x1.8GHz, 2MB L2) met 4GB ddr geheugen en 1x WD raptor 36GB)
- 1x fileserver (2x Opteron 270 (2x2GHz, 2MB L2) met 8GB ddr geheugen en 3x WD raptor 36GB)
- 1x MySQL server (2x Xeon X5355) met 8GB ddr2 geheugen en 8x SAS 15kRPM

Alle servers draaien op CentOS, de webservers met Apache + PHP we hebben GZIP aanstaan.

Voor een overzichtje van de netwerk structuur: klik hier

Ik denk dat wel duidelijk is wat wat is, de loadbalancer heeft een uplink van 100Mbit.

De nodes zijn via 100Mbit met de switches verbonden, de fileserver en dbserver 1Gbit

Hier even een plaatje waar je ziet dat de 4 webservers 8 connecties per seconde te verwerken krijgen:
klik hier
op dit moment waren er 888 gebruikers online ... onze piek = 1365.
De webservers hadden bij 8xx gebruikers online een load van ongeveer 1-2 met kleine pieken van 3 en 4.

Hoe werkt het één en ander;
- php scripts/plaatjes/etc staan centraal op de FILEserver. De webserver kunnen hierbij via een NFS mount.
- php sessies staan ook via een NFS mount op de fileserver

---------Het probleem------------

Het laden van een pagina kan soms even duren, we hebben zelfs tijden van tientallen seconden gezien. Meestal is het rond de 0,0x seconden en daarvan neemt de database de meeste tijd in.

Toch is het wel vreemd dat een pagina willekeurig, ene keer snel andere keer heel sloom laad terwijl er maar 600 gebruikers online zijn. Het gebeurt namelijk op een heleboel manieren.
Ook lijkt het of de connecties soms even vastlopen. het aantal Mbit/s dat de loadbalancer dan verscheept valt dan van 9Mbit/s naar 2-4Mbit/s. Dan ineens lijkt het alsof die alles loslaat en dan krijg je ineens je content terug van de opgevraagde pagina. Dat gebeurt dan simultaan bij alle gebruikers.

Zou het kunnen zijn dat onze fileserver niet capabel genoeg is en daarom de servers even moeten wachten op de scripts?

Ik hoop dat iemand misschien raad weet met deze situatie of in ieder geval tips heeft!

Alvast bedankt.

[ Voor 3% gewijzigd door TheNephilim op 11-05-2007 21:21 ]

[Kokkers]

Ik verwacht niet dat er iemand aan de hand van de gegeven informatie een kant-en-klare oplossing kan geven. Webserver, database, netwerk en fileserver kunnen allemaal verantwoordelijk zijn voor willekeurige 'stalls'. Netwerk errors, database locks, garbage collects, disk load, whatever.

Je hebt performancedata nodig om een indicatie te krijgen van wat er gebeurt.
Je hebt (debug) logging nodig om een indicatie te krijgen van wat er gebeurt.
Wellicht kun je op 1 van je front-ends je PHP code aanpassen met debug code.

Hebben jullie een monitoring server?
Een veel gebruikte oplossing is http://www.cacti.net.

Prachtige templates beschikbaar voor het meten van MySQL, CPU, netwerk, webserver, disk, etc performance.

Ik weet natuurlijk niet wat je host maar aan je hardware zou het niet mogen liggen zo te zien, er zijn mensen die het met minder moeten doen.

[ Voor 8% gewijzigd door Kokkers op 11-05-2007 21:26 ]

[TheNephilim]

Kokkers schreef op vrijdag 11 mei 2007 @ 21:23:
Ik verwacht niet dat er iemand aan de hand van de gegeven informatie een kant-en-klare oplossing kan geven. Webserver, database, netwerk en fileserver kunnen allemaal verantwoordelijk zijn voor willekeurige 'stalls'. Netwerk errors, database locks, garbage collects, disk load, whatever.
Dat is waar, maar we zijn ondertussen steeds bezig met hardware oplossingen en steeds is er wel iets te verbeteren. Elke tip is welkom

Je hebt performancedata nodig om een indicatie te krijgen van wat er gebeurt.
Je hebt (debug) logging nodig om een indicatie te krijgen van wat er gebeurt.
Wellicht kun je op 1 van je front-ends je PHP code aanpassen met debug code.
we kunnen zien welke scripts de meeste tijd gebruiken en queries en dergelijke, maar na wat testen leek het niet echt te vinden waar specifiek de fout zit.

Hebben jullie een monitoring server?
Een veel gebruikte oplossing is http://www.cacti.net.
Een aparte server hebben we er niet voor, cacti hebben we overigens wel eens op onze MySQL server gehad. Maar als ik het goed begrijp kun je het op 1 server installeren en er meerdere mee monitoren? of bedoel je op 1 webnode?

Prachtige templates beschikbaar voor het meten van MySQL, CPU, netwerk, webserver, disk, etc performance.

Ik weet natuurlijk niet wat je host maar aan je hardware zou het niet mogen liggen zo te zien, er zijn mensen die het met minder moeten doen.
Dat is waar, het is trouwens een online game (nee geen criminals ).

Verder vroeg ik me nog af of het serveren van scripts vanaf de NFS (file) server niet het probleem kan zijn.
Met 50 connecties per seconde en ca. 5 includes + script zelf zou hij 50x6 files per seconde van de fileserver af moeten halen als ik het goed reken zo. De plaatjes niet een meegerekend.

[Kokkers]

Dat is waar, maar we zijn ondertussen steeds bezig met hardware oplossingen en steeds is er wel iets te verbeteren. Elke tip is welkom

De meeste winst is meestal op software / architectuur gebied te behalen.
Je zult je bottleneck aan moeten kunnen wijzen.

Een aparte server hebben we er niet voor, cacti hebben we overigens wel eens op onze MySQL server gehad. Maar als ik het goed begrijp kun je het op 1 server installeren en er meerdere mee monitoren? of bedoel je op 1 webnode?

Cacti draai je bij voorkeur op een aparte server.
Cacti is een applicatie die (o.a.) via SNMP, performance data uit kan lezen van andere machines.
Je voorziet al je servers van SNMPD en de counters die je d.m.v. templates specificeert zullen dan periodiek uitgelezen en opgeslagen worden. Deze data kun je vervolgens op commando via de webinterface als grafiek oproepen. Mijnsinziens in een groeiende serveromgeving onmisbaar!
2 willekeurige voorbeelden:
- HTTP en TCP response times http://forums.cacti.net/about11020.html
- MySQL template http://forums.cacti.net/about11010.html

Ik heb zelf geen (high performance) ervaring met NFS. De meningen over NFS performance zijn nogal verdeeld. De 1 zegt dat het hele protocol aan alle kanten rammelt, de ander heeft het naar zeggen (na tweaks en benchmarks) met succes geimplementeerd.

Ik denk wel dat je de hoeveelheid NFS queries zoveel mogelijk wil beperken. Heb je bewust een keuze gemaakt welke data je van je NFS mount wil laden? NFS requests brengen extra latency met zich mee en worden door je webserver niet gecached. Persoonlijk zou ik mijn scripts lokaal op de webservers zetten. Hier worden ze door je webserver / filesystemcache afgehandeld en heb je per pagina request al 6 NFS requests minder!

Voor dynamische data als plaatjes is het handig om deze centraal te hebben op NFS, statische data als scripts zou ik gewoon lokaal houden. Development, distributie en publicatie zul je dan zelf iets voor moeten verzinnen, CVS, SVN, Rsync whatever.

Heb je al eens naar de mogelijkheden van NFSSTAT gekeken (standaard NFS util)?

Wellicht dat jeuit je individuele pagina requests iets op kan maken m.b.v. 'Tamper data' plugin voor FireFox. https://addons.mozilla.org/en-US/firefox/addon/966

Mijn gok; Database locks of NFS issues, maar wat weet ik nou helemaal

[ Voor 5% gewijzigd door Kokkers op 11-05-2007 23:04 ]

[TheNephilim]

Kokkers schreef op vrijdag 11 mei 2007 @ 22:59:
Cacti draai je bij voorkeur op een aparte server.
Cacti is een applicatie die (o.a.) via SNMP, performance data uit kan lezen van andere machines.
Je voorziet al je servers van SNMPD en de counters die je d.m.v. templates specificeert zullen dan periodiek uitgelezen en opgeslagen worden. Deze data kun je vervolgens op commando via de webinterface als grafiek oproepen. Mijnsinziens in een groeiende serveromgeving onmisbaar!
2 willekeurige voorbeelden:
- HTTP en TCP response times http://forums.cacti.net/about11020.html
- MySQL template http://forums.cacti.net/about11010.html

Ok, ik zal eens kijken wat de mogelijkheden zijn. We hebben nog een Core 2 Duo staan als testserver, misschien dat we daar wat mee kunnen.

Ik heb zelf geen (high performance) ervaring met NFS. De meningen over NFS performance zijn nogal verdeeld. De 1 zegt dat het hele protocol aan alle kanten rammelt, de ander heeft het naar zeggen (na tweaks en benchmarks) met succes geimplementeerd.

Ja, dat vond ik ook. Veel verschillende meningen na het lezen van wat dingen erover.

Ik denk wel dat je de hoeveelheid NFS queries zoveel mogelijk wil beperken. Heb je bewust een keuze gemaakt welke data je van je NFS mount wil laden? NFS requests brengen extra latency met zich mee en worden door je webserver niet gecached. Persoonlijk zou ik mijn scripts lokaal op de webservers zetten. Hier worden ze door je webserver / filesystemcache afgehandeld en heb je per pagina request al 6 NFS requests minder!

Dat is waar, we zullen eens zien wat we kunnen doen om de scripts lokaal te krijgen. Moet dan met een sync directory of iets dergelijks.

Voor dynamische data als plaatjes is het handig om deze centraal te hebben op NFS, statische data als scripts zou ik gewoon lokaal houden. Development, distributie en publicatie zul je dan zelf iets voor moeten verzinnen, CVS, SVN, Rsync whatever.

We hebben binnenkort een kleine verandering, we krijgen een nieuwe fileserver (10x SAS 15kRPM 147GB RAID 5 + 1GB raid-cache. Xeon5130 met 4GB geheugen DDR2.
De content zoals plaatjes ed gaan via een static route lopen via de oude fileserver als webserver,

Heb je al eens naar de mogelijkheden van NFSSTAT gekeken (standaard NFS util)?

Heeft mijn collega al eens naar gekeken, dat leverde niet echt wat bijzonders op.

Wellicht dat jeuit je individuele pagina requests iets op kan maken m.b.v. 'Tamper data' plugin voor FireFox. https://addons.mozilla.org/en-US/firefox/addon/966

Mijn gok; Database locks of NFS issues, maar wat weet ik nou helemaal
[/quote]

[CyBeR]

Haal iig je scripts alvast van je file server af. Die veranderen niet dusdanig vaak dat je daar centrale storage voor nodig hebt. Zet die op je webservers en gebruik rsync om te zorgen dat ze allemaal hetzelfde zijn als je 't verandert. Extragratis voordeel: je kunt een server uit je load balanced pool halen om te upgraden, checken of alles nog werkt, en 't daarna pas bij de rest doen. Het scheelt je daarna ook NFS en network latency om die veelgebruikte files te raadplegen.

Verder, gebruik geen apache voor je static content. Apache is log, relatief traag en gebruikt veel geheugen. Kijk daarvoor naar dingen als Boa, lighttpd, of nginx.

Oh, welke kernel gebruikt CentOS eigenlijk? Die "enterprise" dingen willen nog wel 's op 2.4 zitten maar 2.6 is veel en veel beter.

Wat je eventueel ook kunt doen, is er een caching reverse proxy voor zetten. Of dat kan is sterk afhankelijk van je site. Als die veel dynamische info bevat (bijvoorbeeld een forum) is 't niet zo'n goed idee, maar als het grootste deel van de informatie slechts infrequent wijzigt (bijvoorbeeld een nieuwssite) kun je d'r een hele grote speedup mee krijgen. 't is ws. ook wel toepasbaar op online games maar zoals gezegd dat is heel erg afhankelijk van hoe de site in elkaar steekt.

[ Voor 32% gewijzigd door CyBeR op 12-05-2007 13:00 ]

[TheNephilim]

Haal iig je scripts alvast van je file server af. Die veranderen niet dusdanig vaak dat je daar centrale storage voor nodig hebt. Zet die op je webservers en gebruik rsync om te zorgen dat ze allemaal hetzelfde zijn als je 't verandert. Extragratis voordeel: je kunt een server uit je load balanced pool halen om te upgraden, checken of alles nog werkt, en 't daarna pas bij de rest doen. Het scheelt je daarna ook NFS en network latency om die veelgebruikte files te raadplegen.

Jah, dat is zeker een goed idee. Scheelt alweer bergen verkeer.

Verder, gebruik geen apache voor je static content. Apache is log, relatief traag en gebruikt veel geheugen. Kijk daarvoor naar dingen als Boa, lighttpd, of nginx.

Goeie tip, onze static content gaat straks via een andere server... dan kunnen we daar rekening mee houden.

Oh, welke kernel gebruikt CentOS eigenlijk? Die "enterprise" dingen willen nog wel 's op 2.4 zitten maar 2.6 is veel en veel beter.

Linux 2.6.9-42.0.10.ELsmp #1 SMP Tue Feb 27 09:40:21 EST 2007 x86_64 (lijkt me in orde dus)

Wat je eventueel ook kunt doen, is er een caching reverse proxy voor zetten. Of dat kan is sterk afhankelijk van je site. Als die veel dynamische info bevat (bijvoorbeeld een forum) is 't niet zo'n goed idee, maar als het grootste deel van de informatie slechts infrequent wijzigt (bijvoorbeeld een nieuwssite) kun je d'r een hele grote speedup mee krijgen. 't is ws. ook wel toepasbaar op online games maar zoals gezegd dat is heel erg afhankelijk van hoe de site in elkaar steekt.

De content veranderd voortdurend, dit zal niet veel zin hebben. Het is heel interactief. Maar die static route voor plaatjes zal al wel wat oplossen.

Bedankt voor je tips!!

[JMW761]

Welke optimalisaties heb je al doorgevoerd? (aan apache/mySQL/NFS?)

en inderdaad, zoals eerder opgemerkt, hou de load in combinatie met de hoeveelheid verkeer en aantal sessies in de gaten. Waarschijnlijk ga je al snel verbanden zien. Monitor dus verkeer, load en sessies, liefst via grafieken, zodat je de relaties kunt leggen met vorige dagen/weken etc.

[ACM]

Als ik moet raden komt je vertraging door je nfs-machine en/of door je sql-machine, maar er kan ook iets zijn dat hier niet genoemd wordt en waar je zelf ook niet aan dacht. Bijvoorbeeld een DNS-machine die af en toe traag reageert of een intensieve cronjob die op alle servers tegelijk aanspringt.

Wij gebruikten NFS ook op jouw manier met scripts, maar dit bleek regelmatig voor problemen van diverse aard te zorgen (vziw ook stalls). Daarom hebben wij de scripts en de statische files (achtergrondplaatjes enzo) verplaatst naar de lokale schijf van de webservers die we via rsync kopieren.

Bernardo schreef op vrijdag 11 mei 2007 @ 21:06:
- php scripts/plaatjes/etc staan centraal op de FILEserver. De webserver kunnen hierbij via een NFS mount.

Op tweakers hebben we een vergelijkbare architectuur, maar heel bewust de scripts en andere statische onderdelen van de site zelf op de webservers zelf staan. Met jouw opstelling moet je ongeveer de load van tweakers.net aankunnen zonder noemenswaardige vertragingen, mits je softwarematig de boel fatsoenlijk in orde hebt.

- php sessies staan ook via een NFS mount op de fileserver

Dit is een van de dingen die wij niet eens overwogen hebben. Aangezien wij weten welke elementen er in een sessie zitten hebben we een eigen sessiesysteem in mysql die alleen het noodzakelijke bijhoudt (eigenlijk alleen sessieid, userid en wat administratieve veldjes).
Als dat voor jou geen optie is, maar het eventueel wegvallen van je sessies te accepteren is zou je kunnen overwegen om naar 'memcached' te kijken, dat is een daemon die als centrale memory cache kan optreden (en op het oog heeft je fileserver zat geheugen). De bijbehorende PECL-extentie voor php biedt vziw ook session handling daarvoor. Of je zou natuurlijk kunnen overwegen om de sessies gewoon in MySQL op te slaan met een textveld waar de serialized session in staan.

Het laden van een pagina kan soms even duren, we hebben zelfs tijden van tientallen seconden gezien. Meestal is het rond de 0,0x seconden en daarvan neemt de database de meeste tijd in.

Het is lastig te achterhalen, maar je zal toch echt beter moeten zien te vinden waar het ligt. Let bijvoorbeeld op de mysql slow query log. Ik geloof dat de default threshold op 10 seconde staat, maar dat zou je kunnen verlagen naar 1.

Als je al in je php-scripts allerlei timers bijhoudt kan je kijken of bijvoorbeeld de database time ineens toenam op die momenten. Als die gelijk bleef of zelfs door de vertraging afnam kan je in eerste instantie je database uitsluiten. Als een bepaalde query juist ineens enorm toenam zal je daar naar moeten kijken natuurlijk (maar die zou ook in mysql's slow log moeten komen).
Als uberhaupt de executietijd van je scripts niet toeneemt dan zou het zelfs kunnen duiden op een erg lange tijd die nodig is om uberhaupt je php-file te openen.

Als de load op de webservers plotseling toeneemt, terwijl de cpu-belasting niet of nauwelijks stijgt lijkt het me wederom iets met locking. Wij zagen dat gedrag echter zowel met locking-issues op de databases als op de fileserver.

Zou het kunnen zijn dat onze fileserver niet capabel genoeg is en daarom de servers even moeten wachten op de scripts?

Kwa specificaties lijk ie me eerder zwaar overkill dan niet voldoende capabel. Maar je loopt wel kans op ernstige locking-issues als je er alle files vandaan haalt. Zeker als je geen caches hebt ingesteld voor NFS (wat default niet is).

CyBeR schreef op zaterdag 12 mei 2007 @ 12:54:
Verder, gebruik geen apache voor je static content. Apache is log, relatief traag en gebruikt veel geheugen. Kijk daarvoor naar dingen als Boa, lighttpd, of nginx.

Eerlijk gezegd zagen wij maar weinig verschil in load op onze webservers, elke keer als we weer achter een nukkigheid mbt clientside caches ontdekten. Een paar maanden terug konden we iets van 30% requests naar apache besparen door Internet Explorer beter te laten weten dat ie bepaalde files mocht cachen, en we zagen dat eigenlijk helemaal niet terug in de load van de servers zelf.

Wat je eventueel ook kunt doen, is er een caching reverse proxy voor zetten. Of dat kan is sterk afhankelijk van je site. Als die veel dynamische info bevat (bijvoorbeeld een forum) is 't niet zo'n goed idee, maar als het grootste deel van de informatie slechts infrequent wijzigt (bijvoorbeeld een nieuwssite) kun je d'r een hele grote speedup mee krijgen. 't is ws. ook wel toepasbaar op online games maar zoals gezegd dat is heel erg afhankelijk van hoe de site in elkaar steekt.

Net als de vorige tip mbt vervangen/veranderen van webseversoftware is dit een algemene tip, die imho weinig aan dergelijke plotselinge 'stalls' doet, hooguit dat de reverse proxy maskeert dat het gebeurt.

[jep]

Gebruik je wel NFS3? NFS2 gaat gegarandeerd mis op zulke setups.

Verder lijkt me je server setup flink overkill voor wat je host. Nooit slecht hoor, maar 't moet allemaal makkelijk erg snel kunnen zijn.

[Sander]

Ben je ook al eens door alle scripts heen gelopen? MySQL query's geoptimaliseerd (geen select * etc) en dat soort dingen? Daarnaast kun je ook een stuk caching in je scripting doen, bijvoorbeeld een random afbeelding oid kun je gewoon 1 keer per 5 minuten in een cache file donderen. Ook dingen als nieuwsitems en overzichtslijstjes op je frontpage. Deze kun je laten generen op het moment dat je een nieuw item toevoegd, dit je bij elke gewone request toch weer een query.

[TheNephilim]

ACM schreef op maandag 14 mei 2007 @ 07:44:
Als ik moet raden komt je vertraging door je nfs-machine en/of door je sql-machine, maar er kan ook iets zijn dat hier niet genoemd wordt en waar je zelf ook niet aan dacht. Bijvoorbeeld een DNS-machine die af en toe traag reageert of een intensieve cronjob die op alle servers tegelijk aanspringt.

Wij gebruikten NFS ook op jouw manier met scripts, maar dit bleek regelmatig voor problemen van diverse aard te zorgen (vziw ook stalls). Daarom hebben wij de scripts en de statische files (achtergrondplaatjes enzo) verplaatst naar de lokale schijf van de webservers die we via rsync kopieren.

Dat rsync gaan we zeker gebruiken. Dan sluiten we in ieder geval uit.

Dit is een van de dingen die wij niet eens overwogen hebben. Aangezien wij weten welke elementen er in een sessie zitten hebben we een eigen sessiesysteem in mysql die alleen het noodzakelijke bijhoudt (eigenlijk alleen sessieid, userid en wat administratieve veldjes).
Als dat voor jou geen optie is, maar het eventueel wegvallen van je sessies te accepteren is zou je kunnen overwegen om naar 'memcached' te kijken, dat is een daemon die als centrale memory cache kan optreden (en op het oog heeft je fileserver zat geheugen). De bijbehorende PECL-extentie voor php biedt vziw ook session handling daarvoor. Of je zou natuurlijk kunnen overwegen om de sessies gewoon in MySQL op te slaan met een textveld waar de serialized session in staan.

We hebben al eens geprobeerd om de sessies in de database te zetten, dit werkte opzich prima maar toen we het uitrolden traden er wat problemen op.
We gaan voor de memcached optie, die moet het makkelijk aankunnen en als de scripts op de servers zelf staan is er ruimte genoeg voor de sessies. Bedankt voor de tip!

Het is lastig te achterhalen, maar je zal toch echt beter moeten zien te vinden waar het ligt. Let bijvoorbeeld op de mysql slow query log. Ik geloof dat de default threshold op 10 seconde staat, maar dat zou je kunnen verlagen naar 1.

Als je al in je php-scripts allerlei timers bijhoudt kan je kijken of bijvoorbeeld de database time ineens toenam op die momenten. Als die gelijk bleef of zelfs door de vertraging afnam kan je in eerste instantie je database uitsluiten. Als een bepaalde query juist ineens enorm toenam zal je daar naar moeten kijken natuurlijk (maar die zou ook in mysql's slow log moeten komen).
Als uberhaupt de executietijd van je scripts niet toeneemt dan zou het zelfs kunnen duiden op een erg lange tijd die nodig is om uberhaupt je php-file te openen.

Als de load op de webservers plotseling toeneemt, terwijl de cpu-belasting niet of nauwelijks stijgt lijkt het me wederom iets met locking. Wij zagen dat gedrag echter zowel met locking-issues op de databases als op de fileserver.

We kunnen onderaan elke pagina zien wat de tijd was nodig voor de database (ingebouwd in db class) en we zien de tijd die PHP/Apache nodig had om het script te parsen. Slow query log doet niet veel goeds, er staan vaak query's in met 0 seconden (thresshold staat op en ook vaak seconden die je doen denken aan een timestamp van linux. Die duren langer dan dat er servers bestaan iig. Kortom, daar hebben we niet zoveel aan. het lijken rekenfouten te zijn (het is mysql-5.037)

Kwa specificaties lijk ie me eerder zwaar overkill dan niet voldoende capabel. Maar je loopt wel kans op ernstige locking-issues als je er alle files vandaan haalt. Zeker als je geen caches hebt ingesteld voor NFS (wat default niet is).

Eerlijk gezegd zagen wij maar weinig verschil in load op onze webservers, elke keer als we weer achter een nukkigheid mbt clientside caches ontdekten. Een paar maanden terug konden we iets van 30% requests naar apache besparen door Internet Explorer beter te laten weten dat ie bepaalde files mocht cachen, en we zagen dat eigenlijk helemaal niet terug in de load van de servers zelf.

Net als de vorige tip mbt vervangen/veranderen van webseversoftware is dit een algemene tip, die imho weinig aan dergelijke plotselinge 'stalls' doet, hooguit dat de reverse proxy maskeert dat het gebeurt.

De server is op dit moment voldoet prima, de nieuwe is misschien nog overkill, deze hebben we aangeschaft om de toekomstige activiteiten goed te kunnen uitvoeren.
Cachen is voor plaatjes/js/css een goede optie. De rest van de site is té dynamisch.

Bedankt voor de tips!

[TheNephilim]

Gebruik je wel NFS3? NFS2 gaat gegarandeerd mis op zulke setups.

Verder lijkt me je server setup flink overkill voor wat je host. Nooit slecht hoor, maar 't moet allemaal makkelijk erg snel kunnen zijn.

Ik weet zo gauw niet welke versie, maar voor zover ik weet steeds het nieuwste. Ik zal eens kijken

sander- schreef op maandag 14 mei 2007 @ 14:35:
Ben je ook al eens door alle scripts heen gelopen? MySQL query's geoptimaliseerd (geen select * etc) en dat soort dingen? Daarnaast kun je ook een stuk caching in je scripting doen, bijvoorbeeld een random afbeelding oid kun je gewoon 1 keer per 5 minuten in een cache file donderen. Ook dingen als nieuwsitems en overzichtslijstjes op je frontpage. Deze kun je laten generen op het moment dat je een nieuw item toevoegd, dit je bij elke gewone request toch weer een query.

Select * hebben we slechts op 1 enkele plek nodig, dit is gebruikers info ophalen. Dit kunnen we helaas nie anders doen omdat er teveel scripts zijn die we dan na moeten lopen. Verder word ook de meeste informatie gebruikt.

Een kleine opmerking heb ik wel: al onze tabellen zijn MyISAM, we hebben innoDB ooit eens geprobeerd, maar dat was zo vreselijk traag.
Het zou misschien een optie zijn om onze (centrale) gebruikers tabel innoDB te maken. Deze word bij elk script gebruikt voor gebruikers info en elke 60 seconden word de laatste online tijd geupdate.
Misschien dat er daardoor locking problemen ontstaan.

[ Voor 12% gewijzigd door TheNephilim op 14-05-2007 21:29 ]