PDA

Bekijk Volledige Versie : Dedicated server -> Load balancing



klaaskox
05/11/10, 10:41
Ik heb een vraag mbt tot de overstap naar load balancing. Onze (gehuurde) dedicated server blijkt het groot aantal bezoekers niet meer aan te kunnen. Op de server staan 5 (vergelijkbare) websites, Php, en deze maken gebruik van 1 centrale MySQL database. Overal wordt ons geadviseerd load balancing toe te gaan passen. Een aantal vragen over hoe ingrijpend deze aanpassing in het algemeen is:
- Is het slechts een kwestie van onze webhoster vragen een extra server bij te plaatsen of moet hiervoor vaak de hele opzet van het systeem worden aangepast?
- Moet content (afbeeldingen die continu veranderen) steeds gesynced worden of zijn daar automatische oplossingen voor?
- Kunnen beide servers gewoon gebruik blijven maken van dezelfde database?

Ik hoop dat jullie me in de goede richting kunnen sturen.
Alvast bedankt!

Bart L
05/11/10, 10:59
Het is net wat te weinig informatie om duidelijk te krijgen of load balancing wel het e.a. gaat oplossen.

Je zal de eerste niet zijn die gewoon een non-cache omgeving neerzet voor +10k bezoekers en dan valt de winst toch echt op de omgeving zelf te halen.. 99% van de info op een website hoeft niet realtime te zijn, er mag best een paar seconde tussen zitten.. en daarvoor is cache de juiste oplossing.

Daarnaast is mysql vaak de boosdoener als er niet naar indexen op voldoende maten is gekeken e.d.

Anders gezegd, als je het niet over bijzonder kritische realtime data hebt, en onder de 200k pageviews zit per dag (even op voorwaarde dat je niet ergens een atom hebt gehuurd), dan zou ik eerst kijken waar het probleem echt zit.. waarom dat ding het zo druk heeft.

Daarnaast kun je al heel veel winst behalen door Mysql gewoon op een andere dedicated omgeving te zetten bij dezelfde hoster.. Dan kan de webserver geoptimaliseerd worden voor webservers en de mysql server mysql server ;-) Dat scheelt namelijk nogal wat...

Wil je toch perse naar een load balance omgeving... rekening dan op een aardig budget en dan zijn de mogelijkheden eindeloos ;).

Begin bij het begin, waarom heb je load balancing nodig, terwijl blijkbaar nu de setup bijzonder basic is en er dus nog wel het e.a. aan gesleuteld kan worden voordat je de volgende stap neemt.

Alain
05/11/10, 11:15
Als je goed wil gaan balancen heb je wel meer nodig dan alleen een extra dedicated server. Meestal wil je toch wel gaan werken met een centrale storage/SAN.

Ik zou echter eerst uitzoeken of het wel echt nodig is en waar de performance problemen precies vandaan komen. Wij maken regelmatig mee met dat doormiddel van optimalisatie of gewoon een fatsoenlijke server, performance problemen als sneeuw voor de zon verdwijnen. En daarmee bespaar je dus de kosten van een veel duurdere load balancing oplossing.

klaaskox
05/11/10, 11:22
Dank voor jullie reacties!

Op dit moment draaien we ook memcached voor het cachen van objecten, arrays, blokken html etc om de belasting op mysql te verlagen. Daarnaast is een eenvoudige manier van volledige html-caching toegepast door bij elk bezoek te checken of er een cache bestand bestaat (of dat dit na x aantal minuten/uren verlopen is) en vervolgens dit bestand te serveren of de pagina opnieuw op te bouwen en op te slaan met ob_start() en ob_get_contents().

Ik heb het idee dat het probleem op dit moment niet direct bij de database ligt maar meer bij het opbouwen van pagina's door php en het hoge aantal bezoekers. De betreffende websites worden op gezette tijden (12 uur 's middags en 12 uur 's nachts) extreem druk bezocht. Dit omdat de content op die momenten wijzigt.

Wat adviseren jullie om vast te stellen waar de performance problemen vandaan komen?

Bart L
05/11/10, 11:27
Ik zie nog steeds geen getallen wat ik wil zien.. wat is extreem druk?
Wat voor server heb je, hoeveel geheugen, hoe groot is de SQL DB, is je bandwith niet gewoon geknepen door je hoster enz. etc.

Daarnaast kan het ook bijvoorbeeld een I/O probleem zijn, een extra server erbij zetten voor de DB heeft nog steeds mijn voorkeur in dit soort gevallen..

tjvb
05/11/10, 11:28
De hamvraag is denk ik: waar zit de bottleneck?

Alain
05/11/10, 11:36
Je moet toch echt wat performance statistieken (over een langere periode) hebben om er zinnig antwoord op te kunnen geven...

klaaskox
05/11/10, 11:56
Ik begrijp jullie reacties. Zoals jullie misschien al wel vermoedden heb ik niet erg veel ervaring met het monitoren van server performance. Hieronder wat dingen die ik wel eenvoudig op wist te vragen. Als jullie graag andere dingen weten hoor ik t graag.

$free:
total used free shared buffers cached
Mem: 4138024 3941236 196788 0 102908 1357224
-/+ buffers/cache: 2481104 1656920
Swap: 5406712 137936 5268776



$cat cpuinfo:

processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 15
model name : Intel(R) Core(TM)2 Quad CPU Q6600 @ 2.40GHz
stepping : 11
cpu MHz : 1596.000
cache size : 4096 KB
physical id : 0
siblings : 4
core id : 0
cpu cores : 4
apicid : 0
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 10
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc pni monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr lahf_lm
bogomips : 4800.12

(4x deze processor)


$vmstat:
procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu------
r b swpd free buff cache si so bi bo in cs us sy id wa st
1 0 134088 1714236 106432 1395196 0 0 5 75 0 2 15 4 80 1 0

Bart L
05/11/10, 12:17
Lijkt me handiger om iemand in te schakelen die doormiddel van debuggen kijkt waar de bottleneck zit..

Piwi-Web
05/11/10, 12:55
Zoals je zegt weet je niet waar het probleem zit. Lijkt mij een logische eerste stap dat je iemand laat kijken naar waar de botteneck zit.
Ook zal je met meer concrete gegevens moeten komen zoals aantal bezoekers, pageviews p/sec op de tijden dat de server het 'druk' krijgt, Load, etc.
Misschien wilt iemand je server wel in de monitoring gooien (zabbix o.i.d.) zodat je i.i.g. gegevens hebt waar je iets mee kunt en waar iets op af te lezen is. Je bent nu alleen maar aan het gokken wat het probleem kan zijn heb ik zo'n idee

systemdeveloper
05/11/10, 12:58
Waar je naar kunt kijken is:

- wat is de load op piekmomenten en welk proces gebruikt het meeste
- wat is je traffic (in mbits) op dat moment
- check met gstat (oid) wat je diskload is op zo'n moment
- check met mytop het aantal concurrent sql queries
- staan http requests misschien gequeued omdat apache gelimiteerd is op xx processen
- worden je mysql queries wel goed gecached (cache size en blokgrootte groot genoeg) of vreet iets anders het geheugen voor mysql weg

Maar beter is nog altijd om iemand met kennis van zaken te laten kijken op zo'n moment. Eerst de exacte oorzaak weten, dan oplossing binnen je budget zoeken.
En niet vergeten dat (bij wijze van spreken) 16GB extra ram goedkoper kan zijn dan een expert er 2 dagen mee bezig is.

xaban
05/11/10, 13:36
Het is inderdaad moeilijk te zeggen waar het probleem ligt en hoe je dit kunt oplossen, er is grof weg te weinig informatie bekend.

Ik zie dat je server al aan het swappen is geweest, dus sowieso moet er meer geheugen bij (of natuurlijk je code optimalizeren).

Loadbalancen kan op heel veel manieren.

- Bijvoorbeeld 2 servers in sync, met roundrobin DNS.
- Webserver fysiek scheiden met MySQL server.
- Of 2x webserver + 1x MYSQL server.
- En nog wel meer mogelijkheden..

Het beste is een Linux admin/expert inhuren en er naar laten kijken.

Succes!

SHQ
06/11/10, 00:31
Een dergelijke situatie hebben wij een 6 tal maanden meegemaakt.

Nieuwe "dikke" raid server met 8gb mem, welke op rare tijden flink onderuit ging tot onbereikbaar toe.

2de identieke server erbij op verzoek van de klant. Nog steeds zelfde problemen.
Waren 2 websites, 1 gezamelijke database en constant van 0800 tot 2300 een 350 a 400 unieke bezoekers online maar opzich naar gezien de grote van de database moest dat eenvoudig op 1 server kunnen.

Flink wat nagekeken op server gebied, memcache, optimalisering. De setup bleef onderuit gaan.

Klant geïrriteerd, logisch en huurt een debugger voor second opinion in van zijn website op ons verzoek (aandringen)

Wat blijkt. Foute query in zoekvelden welke in een "loop" kwamen en zo alles volbufferde tot server zegt: tot hier en niet verder.

Website is uiteindelijk geoptimaliseerd, draait nu op 1 server terug en zou bij wijze van nog maal 3 erop geplaatst kunnen worden.

Ramon Fincken
06/11/10, 10:07
inderdaad. ook al ga je optimaliseren, vergeet niet dat queries die goed zijn en indexen op je (join of search) tabellen echt een merkbaar verschil hebben.

klaas ik zou graag geheel gratis eens in je code en database willen kijken!

theop
08/11/10, 15:22
voor loadbalancing is het erg belangrijk of de site/app
sessie based (iso laag 7) is of alleen maar tcp sessie
based is

in het laatste geval kan je een eenvoudige loadbalancer
gebruiken (freebsd/ipfilter) kan dat bv

in het eerste geval heb je een toffe load balancer nodig
kijk maar eens naar jetnexus. ik heb gehoord dat ze met
een spla achtig programma bezig zijn dus geen investeringen
maar betalen na gebruik.

theo

klaaskox
10/11/10, 10:46
Dank voor alle reacties!
De problemen zijn inmiddels grotendeels verholpen. We hebben, zoals een aantal van jullie al aangaf, nog geen load balancing te hoeven toepassen, dus bedankt voor dit goede advies.
Ten eerste zijn we de belangrijkste pagina's (meeste bezoekers komen alleen op onze homepages, en zijn niet ingelogd) structureel elke minuut (omdat de content wel steeds kan veranderen) volledig gaan cachen in html files. Dit zorgt ervoor dat we het overgrote deel van de bezoekers eenvoudige gecachete html pagina's kunnen voorschotelen in plaats van ze steeds met php te genereren.
Daarnaast hebben we gzip compressie aangezet en hebben we wat expire headers gezet op JavaScript en afbeeldingen.
Ook de webhoster waar we de server huren heeft nog wat aanpassingen gedaan. Ik meen dat hij het erover had dat ze onder andere "het aantal connecties flink hadden opgehoogd". Ik wil dit binnenkort nog even een keer navragen om wat meer details hierover te krijgen.
We zijn in ieder geval een eind in de goede richting, bedankt voor jullie tips!