PDA

Bekijk Volledige Versie : Website op groei voorbereiden



FransVanNispen
31/05/07, 01:19
Ik zou graag wat tips en ideeën uitwisselen omtrend het volgende:

We hebben een website die momenteel nog uit alleen een forum bestaat draaien. Doorgaans zijn er zo'n 250 simultane gebruikers online, maar vanwege de aard van de content, kunnen dat bij bepaalde media gebeurtenissen er zomaar 600 tot 800 worden.

Omdat we de site behoorlijk willen uitbreiden, en de userbase gestaagd blijft groeien, ben ik aan het bekijken hoe ik het beste met deze groei kan omgaan.

Momenteel draait de site op een Opteron 165 met 4Gb RAM en 2xWD Raptor in RAID1. De database draait op een dual Xeon 5130 met 8Gb en 3xWD Raptor in RAID5

Merkbaar is dat boven de 500 simultane gebruikers lag ontstaat.

Nu dacht ik er zelf aan om de groei voorlopig te staven door de servers aan te passen naar:

Database: dual Xeon 5130, 8Gb en 4xWD Raptor in RAID10
Website verdelen over 2 machines:

Een Core2Duo E6320 met 4Gb, 2xSATA2 in RAID1 als webserver met NFS share voor gedeelde bestanden (avatars).

Tweede webserver Core2Duo E6320 met 4Gb en 1 schijf, omdat de webdata van server 1 zal komen

Deze wilde ik dan via DNS round robin gaan balancen.

Is dit en goede optie om voorlopig vooruit te kunnen, of zijn er betere alternatieven die betaalbaar blijven? Het 'serverpark' van de site moet namelijk niet harder groeien dan de inkomsten van de pagina.

Hpoe zouden jullie dit aanpakken?

SF-Jeroen
31/05/07, 01:41
Voor een forum lijkt me niet dat er lag zou moeten ontstaan bij 500 gebruikers met die servers, wat is de interne verbinding tussen die 2?

FransVanNispen
31/05/07, 01:49
De interne verbinding is 100Mbit, maar de data die daar overheen gaat is ook niet dramatisch. Die zal echter ook naar 1 Gbit gaan.

Lag is een groot woord, maar bij 500+ is het merkbaar dat het drukker wordt. Nu zijn het doorgaans gebruikers die bij een laadtijd van tegen de seconde al beginnen te piepen.

Wellicht dat de 'lag' komt doordat ik nog geen InnoDB gebruik. Ook dat zal worden aangepast voor alle tabellen die iedere minuut worden geupdate.

700 man online gaat nog op de config, maar ik wil graag voorbereid zijn op nog grotere aantallen.

wonko
31/05/07, 08:31
Ik zou zeker eerst eens een analyse doen van de database, als deze optimaal draait, en de config van de webservers. Aan de hand daarvan zou ik hardware aankopen die de gevonden bottlenecks oplost (snellere IO nodig, meer ram nodig, meer proc kracht nodig, niets extra nodig???...)

Ramon Fincken
31/05/07, 08:31
Welke forumsoftware is het?
Gebruik je al template en SQL caching?

Thomas.R
31/05/07, 10:40
Lijkt me idd dat je je scripting is mag na kijken, 500 man voor zo`n machine moet te doen zijn?

trebbor
03/06/07, 13:49
De database heeft hier niets mee te maken. Het gaat echt om de webserver, je zal zien als je de database apart zet op een server dat het bijna geen load geeft, gaat dus echt om APACHE.

Kijk eens naar Apache 2.0 of Apache Lite.

DutchTSE
03/06/07, 15:38
De database heeft hier niets mee te maken. Het gaat echt om de webserver, je zal zien als je de database apart zet op een server dat het bijna geen load geeft, gaat dus echt om APACHE.

Kijk eens naar Apache 2.0 of Apache Lite.
De database draait al op een aparte server.. je kunt zoals wonko zegt beter op zoek gaan naar de bottleneck en die weghalen indien mogelijk dan roekeloos je hardware updaten. Ook je scripting optimaliseren zal al veel helpen.

xYnta
04/06/07, 15:23
Misschien gebruik maken van cronjobs die bepaalde gegevens zoals o.a. de online statistieken om de zoveel minuten vernieuwen en deze vervolgens in een HTML bestand laten genereren en die includen op de desbetreffende pagina, dat kan vaak heel veel load schelen. Ook het cachen van verschillende elementen kan handig zijn en natuurlijk even een optimalisatie draaien van je database.

FransVanNispen
04/06/07, 15:31
De database draait inderdaad al apart. Momenteel draait het aardig, maar er moet op behoorlijke groei worden geanticipeerd.

Met 600 man is de gemiddelde laadtijd nog net onder de seconde, maar merkbaar trager dan normaal.

De database draait momenteel aan een load van 0.4 to 0.6, dit is niet het probleem.

De software is gebaseerd op phpBB, maar behoorlijk aangepast. Diverse queries zijn geoptimaliseerd. Er wordt redelijk wat data gecached in files die eens per minuut, 5 minuten en uur worden geupdate.

De load op de webserver is 0.4 tot 1.2 in die pieken. Er wordt ook bij de drukke tijden niet geswapt naar schijf. Dat kan dus ook niet het probleem zijn.

Ik vermoed dat een deel van het probleem komt door table-locking op MyISAM tabellen. Omschakelen naar InnoDB voor een aantal tabellen kan misschien uitkomst bieden?

xYnta
04/06/07, 15:34
Het overschakelen naar InnoDB zoiu inderdaad in de toekomst problemen uit de weg kunnen helpen, maar ik kan daar niet geheel over oordelen zonder het script zelf te hebben gezien. Maar het is inderdaad wel een mogelijkheid.

VinceSTM
04/06/07, 15:35
Hoi frans,

Gebruik je php in de threaded mode?

Groeten

The Unknown
04/06/07, 18:54
Belangrijk is om te vinden wat de laadtijd veroorzaakt. Kun je de laadtijd niet laten laten uitsplitsen in de tijd die word gewacht op het resultaat van de query.

Die laadtijd van een seconde, heb je die door PHP laten berekenen, of is dat je eigen gevoel? Een loader die de onveranderde PHP scripts cached, kan ook tijdswinst opleveren. Er zijn een aantal gratis php accelerators, of betaalde van zend. En natuurlijk niet PHP als CGI draaien, maar ik ga er vanuit dat je dat niet zo gebruikt :)

Volgens mij moet het grote aantal gebruikers voor apache niet zo'n probleem hoeven zijn, ik denk dat de database eerder problemen zou moeten geven.

En check ook de hardware zelf nog even. De lees en schrijftijden van de HDD (maar gezien dat sata is, zou dat via de SCSI deel van kernel moeten gaan, en hoef je die niet op UDMA in te stellen).

Ik zou ook nog kijken in apache naar dingen als OVERRIDE NONE in de directory config, zodat apache niet in iedere directory hoeft te zoeken naar .htaccess files -> dat kost tijd.

FransVanNispen
04/06/07, 19:03
PHP draait volgens mij niet in threaded mode.

De database server gebruikt een 3Ware 9550SX RAID kaart in RAID5

Voor PHP caching gebruik ik momenteel Zend en eAccellerator

Groovy
05/06/07, 01:18
Misschien inplaats van een RAID-5 te gebruiken, over gaan naar een RAID-10 opstelling?

http://en.wikipedia.org/wiki/Nested_RAID_levels#RAID_10

djalken
05/06/07, 13:28
Heb je apache config al eens getweaked? Dat kan ook schelen kan ik uit ervaring zeggen :) Waardes zoals MaxClients moeten niet te laag staan natuurlijk

LinQ
05/06/07, 13:49
Het lijkt toch eerder een database probleem dan een computer-power probleem. Kunnen er wel voldoende mensen simultaan de database in (mogen er genoeg deamons gestart worden) ?