Bekijk Volledige Versie : Aparte server voor images
T. Verhaeg
14/02/10, 19:49
Heren,
In verband met het beperken van de load zat ik eraan te denken de images vanaf een andere server te halen. Is de load die ik hiermee bespaar aanzienlijk genoeg om het werk erin te steken (op den duur zullen er behoorlijk wat images komen..).
En hoe kan ik zoiets het beste aanpakken, een webserver zoals lightppd installeren, alle files uploaden en de paden aanpassen?
Alvast bedankt!
Dat ligt eraan :)
Load komt meestal niet van de images (correct me if I'm wrong) maar wordt gedaan om de aantal connecties te verdelen over verschillende servers.
Ik zou eerder de SQL verhuizen naar een aparte server (als je dat nog niet hebt) :)
T. Verhaeg
14/02/10, 20:42
Dat ligt eraan :)
Load komt meestal niet van de images (correct me if I'm wrong) maar wordt gedaan om de aantal connecties te verdelen over verschillende servers.
Ik zou eerder de SQL verhuizen naar een aparte server (als je dat nog niet hebt) :)
Nee, heb ik nog niet... Wellicht is dat iets om eens naar te kijken, dus de mysql deamon op een secundaire server zetten, in combinatie met phpmyadmin, poort 3306 open zetten en vanaf het script daar verbinding mee maken, heel even simpel bekeken (terwijl er waarschijnlijk wel het een en ander bij komt kijken, maar dat zoeken we wel op :) ) ?
Triloxigen
14/02/10, 21:10
Ik denk dat je beter eerst kan kijken waar de load in zit, want volgens mij weet je dat nog niet
T. Verhaeg
14/02/10, 21:24
Nou, op het moment is het zo dat ik preventief een aantal oplossingen wil hebben om de load terug te dringen.. Ik verwacht namelijk heel wat pageviews op het moment dat we online gaan, nu heb ik een stresstest uit laten voeren, met 700 pageviews per seconde (wat iets meer is dan dat ik daadwerkelijk verwacht, maar wel een piek kan zijn).
Directadmin geeft hierop een load van laag in de 2.xx wat nét kan met een Dual Core bak volgens mij? Kan ik tijdens tijdens de stress test misschien even top of ps -aux uitvoeren om een beter beeld van de load te krijgen?
Vervelende zou alleen kunnen zijn is dat als je een hoge pageview hebt en je hebt de images ergens anders staan dat je dan je netwerk enorm gaat belasten, dat komt je latency ook weer niet ten goede lijkt mij.
Allemaal leuk en aardig, maar m.b.t. je test:
- wat voor script draai je?
- op wat voor hardware?
- hoe heb je die test uitgevoerd?
- wat draaide er nog meer op dat moment?
- hoe heb je de DA bak geconfigureerd?
- hoe worden de images geladen?
- heb je iets van de MySQL config aangepast, of standaard DA? (waarvan er ook 3 standaard aanwezig zijn)
- blablabla, vindt ik het onzin om zomaar iets te roepen...
T. Verhaeg
14/02/10, 22:14
- Ik draai op een custom script, helemaal geoptimaliseerd..
- Intel Dual Core 1.8 Ghz, 2 GB DDR2, Centos 32b..
-Test is uitgevoerd met een daarvoor bestemd tooltje (naam even ontgaan).
- Op dat moment draaide apache, mysql, bind, dovecot & exim.
- Hoe bedoel je?
- Hoe bedoel je?
- Standaard DA MySQL, valt er winst op te behalen na het tweaken eraan?
Wat zorgt voor de load? Wat is de I/O (iostat)? Je kan met 'ps' heel snel zien wat veel CPU/RAM op zich neemt. Je geeft te weinig info om met een 'oplossing' te komen.
ben wel benieuwd welk tooltje je daarvoor gebruikt hebt..
Ik gebruik s3 van amazon voor fotos ( en alles wat statisch is). Werkt super betaal tussen 5-15 dollar p/m. Host rond de 100duizend bestanden met ongeveer 1/1.5miljoen hits.
http://aws.amazon.com/s3/
http://s3tools.org/s3cmd (cli linux)
http://getcloudfusion.com/ (php framework)
- optioneel CDN (cloudfront)
- kunt CNAME aanmaken (http://media.domein.nl/pic123.jpg)
- ook https
- elke verbinding is ongeveer 300kb/s (cloudfront > 2mb/s)
- het is onbeperkt je betaalt wat je gebruikt/verbruikt
- geen zorgen over backup
Yourwebhoster
14/02/10, 23:13
- Standaard DA MySQL, valt er winst op te behalen na het tweaken eraan?
MySQL: http://help.directadmin.com/item.php?id=44 helpt je iig de goede kant op. Verder valt in andere gevallen ook performance te halen, zoals caching en wellicht het gebruik van een accelerator voor PHP.
Ik gebruik s3 van amazon voor fotos ( en alles wat statisch is). Werkt super betaal tussen 5-15 dollar p/m. Host rond de 100duizend bestanden met ongeveer 1/1.5miljoen hits.
http://aws.amazon.com/s3/
http://s3tools.org/s3cmd (cli linux)
http://getcloudfusion.com/ (php framework)
- optioneel CDN (cloudfront)
- kunt CNAME aanmaken (http://media.domein.nl/pic123.jpg)
- ook https
- elke verbinding is ongeveer 300kb/s (cloudfront > 2mb/s)
- het is onbeperkt je betaalt wat je gebruikt/verbruikt
- geen zorgen over backup
Volgens een aantal berekeningen is Amazon s3 te duur; $150 per TB opslag en per TB dataverkeer als ik het zo zie. Dan kan je beter een eigen server nemen als je de images apart wilt hebben.
Ja staat ook wat tegenover:
- betaalt alleen voor wat je gebruikt (goedkoop voor starters)
- geen zorgen over backup
- uptime tegen de 100%
- extreem schaalbaar
- simpele API , geen gedoe met RAID / filesystems / software (OS,webserver,updates)
- sinds kort ook versioning etc
- geen overboeking, elke verbinding is 300kb/s
Wil je zelf 1TB serveren , moet je ook minimaal 1TB backup hebben.
Naar mate je groeit kun je het anders gaan gebruiken. Door alleen de belangrijkste bestanden erop te zetten en de rest op een eigen server. Of je plaatst er een proxy server met cache voor.
nu heb ik een stresstest uit laten voeren, met 700 pageviews per seconde (wat iets meer is dan dat ik daadwerkelijk verwacht, maar wel een piek kan zijn).
Heb je tijdens het uitvoeren van deze stresstest de MYSQL caching uitgezet? Als je script in real-life wel met muterende data uit MYSQL te maken heeft dan kan een stress test een heel vertekend beeld geven omdat deze vrolijk uit de cache aan het graaien is. Wellicht had je hier zelf al aan gedacht, maar misschien ook niet :)
Iets dat niets kost, simpel is en een antwoord kan geven:
Installeer op je huidige server Nginx en gebruik dat om alle statische content te leveren, de (dynamische) rest stuur je door naar Apache.
In alle gevallen waar ik dit als eerste oplossing heb gedaan scheelde dat aanzienlijk.
T. Verhaeg
15/02/10, 11:22
MySQL: http://help.directadmin.com/item.php?id=44 helpt je iig de goede kant op. Verder valt in andere gevallen ook performance te halen, zoals caching en wellicht het gebruik van een accelerator voor PHP.
Ik maak gebruik van MySQL 5, er wordt in die handleiding specifiek gesproken over MySQL 4. Kan ik dit uitvoeren zonder problemen, of zal ik zelf even gaan zoeken?
Verder heb ik even gekeken naar PHP accelerators, ik zag voornamelijk XCache en Zend Optimizer+. Zijn er verder nog goede accelerators die ik eens kan bekijken?
Verder, kan een webserver zoals lighttpd oplossing bieden?
Ik zou gaan voor APC (http://php.net/manual/en/book.apc.php) , zit ook standaard in PHP6. Standaard is het al flink sneller (200%).
Wijzig in php.ini
apc.stat=off
naar
apc.stat=on
En je hebt een snelheidswinst van 400%. De HD wordt niet meer aangeraakt.
T. Verhaeg
17/02/10, 14:18
Ik zou gaan voor APC (http://php.net/manual/en/book.apc.php) , zit ook standaard in PHP6. Standaard is het al flink sneller (200%).
Wijzig in php.ini
apc.stat=off
naar
apc.stat=on
En je hebt een snelheidswinst van 400%. De HD wordt niet meer aangeraakt.
Heb je hier persoonlijk ervaring mee, of zijn er mensen die hier persoonlijk ervaring mee hebben?
Ja, bij ons werkt het super. Je kunt het zelf gemakkelijk testen, draai Apache Benchmark
1) zonder cache
2) met cache
3) met cache en stat=off
Tevens foutje, het is
apc.stat=on
naar
apc.stat=off
:)
Ja staat ook wat tegenover:
- betaalt alleen voor wat je gebruikt (goedkoop voor starters)
- geen zorgen over backup
- uptime tegen de 100%
- extreem schaalbaar
- simpele API , geen gedoe met RAID / filesystems / software (OS,webserver,updates)
- sinds kort ook versioning etc
- geen overboeking, elke verbinding is 300kb/s
Wil je zelf 1TB serveren , moet je ook minimaal 1TB backup hebben.
Naar mate je groeit kun je het anders gaan gebruiken. Door alleen de belangrijkste bestanden erop te zetten en de rest op een eigen server. Of je plaatst er een proxy server met cache voor.
Het niet maken van Backups omdat het bij Amazon staat is een doodzonde, wat nou als een scripter je spul hacked en je S3 storage helemaal leeg gooit? Dan ben je het alsnog kwijt... En zo zijn er natuurlijk altijd meerdere scenarios te bedenken.
Wil ik nog wel even op reageren. Het idee achter Amazon s3 is dat ze data verlies 100% proberen uit te sluiten. Wat tot nu toe ook gelukt is.
Wat jij bedoelt is dat een server zelf niet actief moet back-uppen, maar het beter is dat een andere server de data download en dit opslaat (of upload naar Amazon s3). Wanneer je server gehackt wordt heeft men dan geen toegang tot jouw backup medium.
Bakker ICT
17/02/10, 22:48
Uhm, als ze bij je storage komen kunnen ze het toch weggooien ? Of kan S3 nog terug in de tijd ...!? Lijkt me niet, denk dat je dan op de block storage misschien backups kan maken?
Even vermelden dat ik S3 ten stelligste *afraad* voor images te hosten. S3 is leuk voor pdfs, mp3s, documenten, file downloads enz. Maar het is meestal te traag voor gewone website images. De latency loopt snel op, je hele site wordt traag als je er een paar hebt staan. Bovendien is het zo goedkoop ook niet.
Ik raad wel aan een afzonderlijke, minimalistisch geconfigureerde, high-speed webserver te zetten voor je images, als je veel images hebt.