wanneer ga je over op meerdere servers?

Het ligt natuurlijk aan zoveel factors, heb je een superzware download site of gewoon een tekst nieuws site, en wat voor hardware hangt er nu, een Xeon of een P4.

Ik denk dat je de load in de gaten moet houden van de server, als deze standaard te hoog is, dan wordt het wellicht tijd om een 2e server erbij te trekken.

Het makkelijkst is dan om je apache en database servers te scheiden, dan heb je het minste gezeur met loadbalancing en clustering etc.

Serverload en performance in de gaten houden.
Als de load erg hoog begint te worden en zodoende de performance beinvloed dan wordt het zinnig om bijv. een 2e webserver / dedicated database server neer te zetten.
Er is niet echt een fixed moment om dat te doen, is helemaal afhankelijk van hoe je server presteert en hoe je site in elkaar zit.

Een belangrijke onderliggende vraag is hoe je kosten verdeeld zijn. Extra HW aanschaffen is goedkoop, extra mankracht duur - met name voor custom SW. Dus als je enigzins elegant extra HW kwijt kunt - bijvoorbeeld door je statische content naar een separate server te verhuizen, en je DB ook een eigen server te geven - dan is dat vaak de voordeligste oplossing.

isomis schreef op dinsdag 19 januari 2010 @ 10:53:
[...]
zie dat ik dit nu heb: Load Average 0.00, 0.06, 0.07

Op het drukste moment nog eens kijken. Qua load zou je zo naar 14.000 of 140.000 bezoekers kunnen doorgaan, met één machine. Een load van 1 is niet problematisch en misschien niet eens merkbaar.

Arnout schreef op dinsdag 19 januari 2010 @ 11:10:
[...]

Op het drukste moment nog eens kijken. Qua load zou je zo naar 14.000 of 140.000 bezoekers kunnen doorgaan, met één machine. Een load van 1 is niet problematisch en misschien niet eens merkbaar.

Een load van 1 op een dualcore proc is zo goed als onmerkbaar bij servertoepassingen. Er komt pas een probleem als de load in de buurt komt van het aantal cores.

Tweakers.net kan ook op één server draaien _{met de specs van de huidige databaseserver, en met de schijven van de fileserver voor de opslagruimte}. Uit het oogpunt van redundantie is dat alleen onwenselijk. Je moet je afvragen wat er gebeurt als de server nu overlijdt, hoelang ben je dan down _{en welke data is weg}?

Even voor de beeldvorming, ik heb een dedicated single xeon server 2Gb geheugen draaiende onder ubuntu met daarop een aantal phpBB's (die gemiddeld 100 a 150 concurrent users hebben) en een aantal wordpress log's die niet zo heel vaak bezocht worden. En mijn server load : load average: 0.01, 0.08, 0.08. Deze machine serveert ongeveer een 100K pages per dag, waarbij er eigenlijk niet 1 static is

Wat bij mij behoorlijk wat geholpen heeft om de load lager te houden is het goed tweaken van mysql, meer geheugen aan de sort, join en key buffer toe te wijzen, en APC voor php aan te zetten.


Ik denk dat je moet je pas echt zorgen gaan maken als je load constant boven de 3 uit komt, en in dat geval kun je denk ik nog wel een tijdje lekker verder groeien met je site en hoef jij je totaal niet druk te maken over dat de server het te druk krijgt


meer info over die load cijfers : http://www.teamquest.com/resources/gunther/display/5/

kwaakvaak_v2 schreef op dinsdag 19 januari 2010 @ 11:22:
meer info over die load cijfers : http://www.teamquest.com/resources/gunther/display/5/

Die pagina is uit 2003 en geschreven voor single-core cpu's.

Maar optimalisatie is uiteraard belangrijk. Wat dat betreft heb je geluk dat je wordpress-installaties klein zijn, want WP is slecht geoptimaliseerd. Daarnaast zou ik je key buffer vergeten en overstappen op InnoDB en een zeer recente MySQL-versie (5.5 is mooi voor InnoDB tegenwoordig).

Single core of multicore maakt voor de werking van het load stukje niet zoveel uit,omdat het de load van de machine middelt en weergeeft, en niet de load per processor.

InnoDB heeft geen fulltext search, dus moet er naast weer een andere search indexer gaan draaien, nu is dat allemaal geen probleem maar het is optimalisatie de verkeerde kant op in mijn optiek. myisam doet het prima, en de performance winst die je krijgt door naar inno te gaan is te verwaarlozen, omdat je dan weer geheugen etc verliest aan een andere fulltext index. Die fulltext is juist wat er voor zorgt dat phpBB goed kan zoeken. Standaard maakt phpBB een eigen formaat aan met key's en indexes, wat er voor zorgt dat een insert van een post met veel tekst nodeloos lang kan duren (om maar te zwijgen over als je een mass-delete/prune) doet.

Zo zie je maar, er bestaat geen 'best' practice, maar moet je kijken naar wat je hebt en daar je configuratie op afstemmen en niet de techniek leidend laten zijn

kwaakvaak_v2 schreef op dinsdag 19 januari 2010 @ 11:48:
Single core of multicore maakt voor de werking van het load stukje niet zoveel uit,omdat het de load van de machine middelt en weergeeft, en niet de load per processor.

Een load van 3 wordt in het artikel gepresenteerd als kritiek, terwijl dat op moderne serverhardware_{met iets meer dan 3 cores} geen enkel probleem is. Het gaat om de verhouding tussen load en aantal cores.

InnoDB heeft geen fulltext search, dus moet er naast weer een andere search indexer gaan draaien, nu is dat allemaal geen probleem maar het is optimalisatie de verkeerde kant op in mijn optiek. myisam doet het prima, en de performance winst die je krijgt door naar inno te gaan is te verwaarlozen, omdat je dan weer geheugen etc verliest aan een andere fulltext index. Die fulltext is juist wat er voor zorgt dat phpBB goed kan zoeken. Standaard maakt phpBB een eigen formaat aan met key's en indexes, wat er voor zorgt dat een insert van een post met veel tekst nodeloos lang kan duren (om maar te zwijgen over als je een mass-delete/prune) doet.

Als je een fulltext-index gebruikt kun je performance vergeten op een grote site. Het is leuk voor het forum van de lokale tennisclub, maar bij de keuze voor een aparte searchengine is de afweging performance versus apart geheugen snel gemaakt.
Op je populaire site zal locking je overigens naar InnoDB dwingen, waarbij je een schaduwkopie aan moet houden wil je nog een fulltext index kunnen gebruiken. Dat is een veel ergere vorm van verspilling van geheugen.

kwaakvaak_v2 schreef op dinsdag 19 januari 2010 @ 11:48:
InnoDB heeft geen fulltext search, dus moet er naast weer een andere search indexer gaan draaien, nu is dat allemaal geen probleem maar het is optimalisatie de verkeerde kant op in mijn optiek.

Dat is een van de beste optimalisaties die je kan doen, want fulltext performance zuigt met een niet eens schokkend aantal rows al kamelenballen.

myisam doet het prima, en de performance winst die je krijgt door naar inno te gaan is te verwaarlozen

Transacties en enige betrouwbaarheid zijn ook wel leuke features.

Check overigens http://highscalability.com/ voor use cases etc. Erg goede site.

Verder een beetje kosten/baten verhaal. Je kan met aggresive caching en andere optimalisaties je website in ieder geval heel lang op weinig servers houden. Maargoed, als je website serieus geld op gaat leveren dan laat je je beheerpartij dit soort dingen gewoon regelen.

Let ook op dat je architectuur waarschijnlijk op de schop moet als je switcht naar meerdere servers, er wordt zelden rekening mee gehouden.

[ Voor 16% gewijzigd door creator1988 op 20-01-2010 14:21 ]

GlowMouse schreef op dinsdag 19 januari 2010 @ 11:19:
Tweakers.net kan ook op één server draaien _{met de specs van de huidige databaseserver, en met de schijven van de fileserver voor de opslagruimte}. Uit het oogpunt van redundantie is dat alleen onwenselijk.

Ik denk niet dat we dat redden met 1 zo'n machine. We hebben inderdaad per server aardig wat overcapaciteit, maar om nou dan maar gewoon alles op een hoop te vegen en te hopen dat het nog goed gaat... Dat is wel weer het andere uiterste.

Sowieso heeft de databasemachine niet echt genoeg schijfruimte om zowel de mysql-database als de xapian-indexen beide goed kwijt te kunnen. Afgezien daarvan heeft de fileserver natuurlijk niet echt genoeg schijfruimte om zichzelf te backuppen

GlowMouse schreef op dinsdag 19 januari 2010 @ 11:54:
Een load van 3 wordt in het artikel gepresenteerd als kritiek, terwijl dat op moderne serverhardware_{met iets meer dan 3 cores} geen enkel probleem is. Het gaat om de verhouding tussen load en aantal cores.

Dat hangt er natuurlijk van af waar de load door veroorzaakt wordt. Als je een load van 16 goed vindt, terwijl dat betekent dat die 16 processen die tegelijk met de disks bezig zijn... dan kan je toch maar beter op een wat lagere load mikken (of het aantal cores verlagen, danwel het aantal diskio's verhogen, voor zover mogelijk).

kwaakvaak_v2 schreef op dinsdag 19 januari 2010 @ 12:07:
Nogmaals dat hangt 100% van wat je hebt. Een forum als fok, met 1000'en concurent gebruikers is iets anders dan een niche forum met gemiddeld 100 concurent gebruikers, en dan nog hangt het er vanaf of de zoek functie vaak gebruikt wordt.

De term concurrent gebruiker is nogal zinloos bij het beoordelen van de benodigde capaciteit van een website. Het geeft wel een indicatie van je belasting, maar je zal toch echt naar het aantal pageviews moeten kijken om te zien wat je aan werk moet doen.
Het is wel zo dat een site met meer bezoekers in een kort tijdsbestek (wat jij waarschijnlijk bedoelt met concurrent gebruikers), ook meer pageviews (bijna) tegelijk moet zien te produceren.

Als er nauwelijks gezocht wordt, maar het meer een slowchat forum is, zou ik het nog steeds aan durven om het fulltext te doen ipv een Lucene of consorten in te zetten.

Juist een slowchat-forum loopt natuurlijk heel hard op, dus dan is de beroerde schaalbaarheid van MySQL's full-text oplossing eerder een nadeel. Sphinx en vergelijkbare omgevingen die zich met de database laten integreren zijn ook dan nuttig.

Mijn ervaring is dat je dingen wel in het juiste perspectief moet blijven zien, en je techniek afstemmen op de behoefte die er is, niet op de behoefte die er misschien ooit wel eens kan zijn.

De boel in de basis schaalbaar opzetten is op zich een goed idee. Maar je moet inderdaad wel uitkijken dat je niet enorm gaat zitten over-engineeren, enkel omdat een bepaald onderdeel misschien ooit niet meer goed tegen de belasting blijkt te kunnen.

De TS draait een gemiddelde site, en kan zich voorlopig drukker maker over het promoten van zijn site dan nu al wakker te liggen over dat zijn techniek niet toereikend gaat zijn.

Eens.