Dedicated webserver en 500K visitors per dag*

[reshi]

Hallo mensen,

Met mijn beperkte kennis heb ik al een uur of 4 Google afgezocht, hier op het forum gezocht en meerdere bedrijven gebeld over het volgende...

Ik heb een dedicated server met de volgende specs:
Intel Core2Duo 2.0 Ghz Dual Core
2GB werkgeheugen
1x160GB SATA2
500GB dataverkeer in de maand

Nou heb ik een bezoekersaantal van 500~600 bezoekers per dag dus dat is nog geen probleem. Door omstandigheden wordt dit binnenkort eerder 20.000 100.000 per dag (misschien nog wel meer hopelijk) en nou vroeg ik me af of bovenstaande dit aan kon of dat ik een veel zwaardere machine nodig heb.

Nou heb ik ondertussen al in de gaten dat dit van nogal veel variabelen afhangt, zoals:
De website en wat mensen daarop kunnen doen. Hoeveel database query's etc
De hardware van de server
De netwerkverbinding naar het internet
etc..

De site waar het omgaat zal geen mysql query's uitvoeren (behalve als iemand het aanvraag formulier invult) en de site zelf zal niet groter zijn dan 300kbytes.

Na contact te hebben gehad met mijn host is het netwerk/data verkeer het probleem niet volgens hun en is het dus alleen de vraag of de boven genoemde server het aan kan.

Heeft iemand hier ervaring mee? En kan iemand aangeven wat zo'n server (mits redelijk geconfigureerd) aan zou moeten kunnen kwa piek bezoekers per seconden?

Alvast bedankt!

[gorgi_19]

Heel flauw antwoord wellicht, maar gooi er eens een stress test overheen (Google linkje). Je kan dan zien hoeveel pagina's per minuut er geserved kunnen en wat de belasting gaat zijn. Vervolgens kan je beredeneren wat je zelf ook gewenst vindt.

Wat een server aankan is ook heel wisselend. Ik heb onderdelen van pagina's gezien die 20 requests / second aan konden en 400.

[ Voor 15% gewijzigd door gorgi_19 op 30-11-2009 16:55 ]

[CyBeR]

Ga er alvast maar vanuit dat als je php gebruikt dat die 2GB te weinig is. Dat is het eerste waar shit op vastloopt namelijk: als je veel apache's tegelijk hebt die vanwege php veel geheugen slurpen dan loopt 't geheugen vol en dan wordt alles zo traag dat je jezelf liefst van kant maakt.

[DiedX]

In hoeverre is je site verder statisch? Als je alleen maar statische zaken hebt dan is die 20.000 echt peanuts. Eea hangt echt af van je programmeerkennis, maar met deze kennis neig ik naar: doen. Geheugen kan je altijd uitbreiden?

[reshi]

Bedankt voor alle jullie reacties!

Alle content is statisch behalve het formuliertje en door voor is php geen probleem. Heb ook al gekeken naar een stress test, maar zo'n test laten doen kost nogal wat en is mss zonde van het geld. Daarom vraag ik het hier, ik hoop dat mensen met ervaring kunnen aangeven of de server het niet red, mss red of makkelijk aan kan. Nou lijkt mij het niet dat de server het makkelijk aan kan, maar ik heb hier geen ervaring in. Nogmaals daarom vraag ik het hier

Iemand anders die hier ervaring mee heeft?

[Verwijderd]

Op zich kan die server het makkelijk aan denk ik. Ik heb wel wat andere vragen over die server...

Qua specs zou het een redelijk basic Dell PowerEdge R300 kunnen zijn. Op zich leuk, maar waarom een enkele harddisk in die server?

En 2 GB geheugen is wat aan de krappe kant, maar voor een statische website zal het doorgaans voldoende zijn. Welk besturingssysteem wordt er gebruikt? Bij een Linux-variant zou je kunnen denken aan nginx of lighttpd in plaats van Apache als webserver. Die hebben een kleinere footprint.

[reshi]

Ja sorry, basic info als OS vermelde is ook handig...

Het gaat om een linux machine met apache.

Het is op de pagina allemaal static content behalve het contact formulier. Mensen kunnen wel via de pagina naar andere delen van de site. Waaronder joomla, maar dat is alleen voor het nieuws en we verwachten niet dat veel mensen daar naar toe zullen gaan.

Hoeveel mensen zou je zeggen dat zo'n server per sec aan kan dan?

[Pete]

Heb je al geprobeerd een benchmark te draaien als de apache benchmark ab?

[reshi]

Pete schreef op dinsdag 01 december 2009 @ 09:58:
Heb je al geprobeerd een benchmark te draaien als de apache benchmark ab?

Nee, mijn kennis gaat niet zover dat ik dat "even" probeer, had het namelijk al wel gevonden. Mss toch iets waar ik naar ga kijken.

[KryTech]

En wat gebeurd er als de server om wat voor reden dan ook uitvalt, ik denk niet dat het acceptable is als de site er een dag uitligt? Misschien zowiezo handig om een tweede server ernaast te hangen en te gaan loadbalancen, ben je ook niet afhankelijk van 1 stukje hardware...

[dvdheiden]

Sowieso zou ik niet voor 1 SATA schijf gaan, veelal zijn de I/O's relatief het langzaamst en daarmee dus de bottleneck. Zeker bij veel kleine I/O's zou ik sowieso kijken voor een SAS schijf of het relatief nieuwe SSD (voornamelijk voor de lagere access time t.o.v. de SATA schijf) al dan niet in RAID 1 (afhankelijk van het belang/voor de redundantie).

Bij veel database gebruik zou ik het geheugen verhogen, maar aangezien je aangeeft dit weinig te doen is dat niet het belangrijkst. Bij ons heeft dit een zeer grote winst opgeleverd door van 4GB naar 16GB te gaan waardoor veel database operaties direct vanuit het geheugen kunnen plaatsvinden.

[ Voor 6% gewijzigd door dvdheiden op 01-12-2009 10:23 ]

[DiedX]

Ik weet niet hoeveel data je hebt? Ik kan me voorstellen dat serveren uit een ramdisk interessant kan zijn?

[CyBeR]

DiedX schreef op dinsdag 01 december 2009 @ 17:10:
Ik weet niet hoeveel data je hebt? Ik kan me voorstellen dat serveren uit een ramdisk interessant kan zijn?

Da's niet echt nodig. Linux cachet zelf al filesystem objects met vrij geheugen. Het enige wat je bereikt door 't zelf te doen is geheugen opslurpen die dan opeens niet meer voor andere dingen gebruikt kan worden.

[ Voor 21% gewijzigd door CyBeR op 01-12-2009 17:14 ]

[DiedX]

True. Ik zou dan gewoon een server met 2GB nemen. Meer lijkt mij niet nodig, maar wellicht dat TS even aankan geven hoeveel zijn app neemt...

[Gomez12]

Tja, simpel gezegd ( geen idee hoe de website nu is opgebouwd ) zou ik gewoon alles statisch zetten behalve het aanvraag formulier. Geen php oid, gewoon 100% oldschool statische html.

Dan voldoet je server de 1e tijd nog ruim. 100.000 pageviews per dag is complete peanuts zolang het enkel statische pagina's zijn. Als het 100% gelijkmatig verdeeld is zou het 1,16 pageviews per seconde zijn.

Doe het even x12 ( is vrij extreem, meestal heb je meer dan 2 uur per dag bezoekers ) dan zit je nog maar op zo'n 25 pages per seconde... Dat trekt een 486 nog makkelijk zolang het maar statisch is.

[CyBeR]

Als je 't zo doet, denk dan aan iets anders dan apache met php ingebakken. Bijvoorbeeld nginx met php als fastcgi module. Dan wordt dat alleen aangeroepen als er echt gephp't gaat worden ipv voor elke request. En inderdaad, dan kun je heel veel requests aan zonder moeite.

[MAX3400]

Ondanks heel veel ideeen en benchmarks en "stukjes" webserver, waar gaat het nou om?

Ongeveer 300KB aan data moet statisch worden afgeserveerd aan de bezoeker tenzij er een formulier wordt ingevuld. Nou ben ik echt geen whizzkid maar ongeacht Unix/Windows, lijkt me toch dat disk-I/O in ieder geval buiten beschouwing gelaten kan worden of kennen we echt geen http-daemon die 300K in het RAM kan bewaren?

Wat houden we dan grof over? Een disk die de hele dag niks doet, een CPU die eigenlijk vrij weinig uitspookt en voldoende dataverkeer om afgerond 190 bezoekers PER seconde de statische data van 300KB uit het RAM toe te kennen.

Verder lees ik simpel in de topicstart; er wordt geen mysql gedaan tenzij iemand een formulier invult. En dan? Je wil de ingevulde velden wegschrijven in een db? Of er hangt een db van 100GB achter die 5 minuten nodig heeft om een ingevuld formulier aan te vullen met andere gegevens? Mogelijk moet het design van de site (technisch dus) eens haarfijn uitgelegd worden want met wat mogelijkheden tot caching, batch-transactions en dergelijke zaken, kan de eventuele mysql-query ook worden uitgesteld tot een later tijdstip.

fyi; de hardware die je op het oog hebt, zie ik onder Debian rustig 6MB/s uplink en downlink random data over de NIC gooien (en dus ook schrijven naar disk en/of cachen voor uitgaand) zonder ook maar een greintje pijn. Iets zegt me, maar hoor graag een andere/onderbouwde mening, dat de hardware overkill is, je afgekochte bandbreedte overkill en dat je waarschijnlijk voor minder dan een paar tientjes in de maand klaar kan zijn bij verschillende hosters in deze wereld.

[aKra]

Static content moet wel lukken, zolang je inderdaad Apache goed geoptimaliseerd hebt. Of kijk bijvoorbeeld naar LightHTTPd, die kan ook veel static content (ook wel PHP met modules mogelijk) tegelijk serven met lage loads!

Als er PHP bij komt kijken, misschien is eAccelerator dan een goede tip, die cached zoveel als mogelijk.

Maar ik denk dat je wel vast komt te zitten met het weinige geheugen, dan gaat het geheel swappen en dan stopt het er wel zo'n beetje mee

[reshi]

Bedankt voor alle reacties!

Ik heb nu wel een ongeveer een beeld van wat ik nodig heb, maar ik heb nog 2 vragen:

In plaats van 100.000 bezoekers gaan we nu richten de 500.000 bezoekers, kan dit dan nog steeds met de bovenstaande configuratie(er veranderd niks aan de pagina zelf)? Ik vraag me dan vooral af of de 2GB werkgeheugen voldoende is, omdat ik hier van meerdere mensen lees dat ze zich afvragen of die 2GB werkgeheugen met 100.000 bezoekers wel voldoende is. We verwachten dus ook hogere aantallen bezoekers kwa pieken, dus de bezoekersaantallen per seconde. De exacte aantellen is uiteraard lastig in te schatten.

Nog wat extra informatie na aanleiding van de post van MAX3400:
We willen inderdaad de gegevens uit het contact formulier wegschrijven in de DB samen met bijvoorbeeld de afkomst(IP) van de gebruiker en de tijd van de aanvraag.
De database waar het omgaat is momenteel "maar" 3MB.
De data zal in een lege nieuwe tabel gezet worden.
En gebruik maken van LightHTTPd is op de korte termijn geen optie, omdat we dan voor de zekerheid eerst de hele site waar de pagina op komt te staan ook weer moeten testen etc..

[ Voor 11% gewijzigd door reshi op 03-12-2009 09:41 ]

[Meulugar]

Waarom draai je nou geen benchmark? maak desnoods eerst een image van je server.

[MAX3400]

Ik zie nog steeds het probleem niet...

500K bezoekers per maand. Laten we even zeggen; allemaal tussen 07:00 en 22:00 komen ze op je site, dat is 15 uur per dag. Dat is 0.3 pageview (500K / 30 * 15 * 3600) per seconde... Stel nou dat iedereen ook meteen zijn formulier invult, dan heb je ook meteen 0.3 records per seconde weg te schrijven. Pak even een groot record (wat, 2500 var-chars) en je schrijft "maar" 1250MB aan data weg in een maand...

Wederom; ik ken de webservers of databases misschien niet goed genoeg maar zelfs dat moet toch lukken? Denk alleen dat het een mooi idee is om de formuliergegevens regelmatig uit te lezen (backupje trekken naar ergens anders ivm single disk server) en daarna de db te flushen.

En inderdaad; wat sommige al zeiden; maak een testopstelling, draai een benchmark en kijk wat eruit komt...

[axis]

Precies.. benchmarken, benchmarken, benchmarken.. Ik snap dat je daar nu nog niet veel vanaf weet, maar het zal de moeite lonen om dit soort kennis te verkrijgen.. Niet alleen nu, maar de rest van je IT-carierre als webbouwer zul je hier mee te maken gaan krijgen.

Ik denk ook dat je naar request/sec to moet als metric om naar te streven in plaats van 'gebruikers per dag', want dat is eerder een management-term die niet veel zegt over je serverload, hoewel die getallen wel gelijk op zullen gaan als er verder geen andere factoren veranderen.

Ik zou squid in reverse mode voor je apache zetten (dat doe ik ook bij veel projecten), dan weet je zeker dat die 300k uit cache geserveerd wordt, en squid is erg goed in wat ie moet doen, namelijk snel requests afhandelen. Zo moet je met je servertje makkelijk 500-1000 requests/sec af kunnen handelen van de statische content.

En hoeveel procent van je gebruikers vult nu het formuliertje in? Ook wel relevant. Is dat iedereen? Of slechts 1%?

En wat meet je nu voor server metrics? Meten is weten. Als je nu grafiekt wat je load is over tijd, dan kun je makkelijker trends herkennen, en zien wanneer het tijd is om over te gaan naar een extra server. Maar volgens mij moet je (mits je php code en mysql allemaal goed getuned zijn) toch wel heeeeel veel gebruikers kunnen serveren met zo'n simpele applicatie.

[Gomez12]

axis schreef op vrijdag 04 december 2009 @ 16:18:
Ik zou squid in reverse mode voor je apache zetten (dat doe ik ook bij veel projecten), dan weet je zeker dat die 300k uit cache geserveerd wordt, en squid is erg goed in wat ie moet doen, namelijk snel requests afhandelen. Zo moet je met je servertje makkelijk 500-1000 requests/sec af kunnen handelen van de statische content.

Toch wel grappig, ik had altijd het idee dat squid enkel zin had omdat het statische pagina's serveerde waar apache dynamische moest maken ( oftewel java / php / python pagina's als backend ).

Als je apache ook gewoon statisch laat serveren dan heeft squid imho heel erg weinig meerwaarde. Als het al niet slechter gaat werken omdat je er gewoon een stap tussenzet.

Serieus, knal het statisch neer en je hebt aan apache voldoende.

Waar hebben we het in vredesnaam over? 10 pagina's met plaatjes oid dat het in 300Kb past. Enkel een verwachte load van 500.000 pageviews ( wat is de realistische? )

Imho is dit allemaal gewoon premature optimisation...

[CyBeR]

Gomez12 schreef op vrijdag 04 december 2009 @ 18:47:
[...]

Toch wel grappig, ik had altijd het idee dat squid enkel zin had omdat het statische pagina's serveerde waar apache dynamische moest maken ( oftewel java / php / python pagina's als backend ).

Als je apache ook gewoon statisch laat serveren dan heeft squid imho heel erg weinig meerwaarde. Als het al niet slechter gaat werken omdat je er gewoon een stap tussenzet.

Serieus, knal het statisch neer en je hebt aan apache voldoende.

Niet helemaal. Als je php gebruikt zit je bijna vast aan apache's prefork mode. D'r zijn wat omwegen maar php in apache werkt het best als je prefork gebruikt.

Wat er dan dus gebeurt is dat voor elke request, zelfs voor statische files, een complete apache met php geladen in actie komt. Da's best overdreven. Bovendien kan apache in prefork mode niet echt goed omgaan met veel client requests tegelijk. Als je namelijk een plaatje aan het serven bent moet je apacheproces, inclusief php en watnogmeer en bijkomend geheugengebruik, actief bezig blijven met die client zolang als 'ie nodig heeft om je file te downloaden.

En daar kan een reverse caching proxy zoals varnish helpen (squid is een forward proxy waar reverse proxy'en een beetje een afterthought in is, en bovendien is 't flink langzamer dan de modernere proxy's). Die offload dat hele clientgebeuren van je apache vandaan. Dan heb je dus een lean, mean varnishproces dat je static files uit cache serveert en zich bovendien bezighoudt met de client. Apache hoeft alleen maar een file te genereren (of op het fs uitzoeken als varnish 'm nog niet of niet meer gecached had), die aan varnish door te geven (dat gaat retesnel) en dan is 'ie klaar. Varnish does the rest.

Een goede reverse proxy voor je site hangen is eigenlijk altijd een goed idee als je een beetje geeft om performance. En dat is dus niet nodig als je 20 bezoekers per dag hebt, maar we hebben 't hier over wat meer mensen. En zo'n reverse proxy hoeft niet eens te cachen, trouwens. Pound bijvoorbeeld cachet niet, maar regelt wel dat clientgebeuren bij je apache vandaan. Dat kan in sommige situaties ook al heel wat schelen.

[ Voor 4% gewijzigd door CyBeR op 04-12-2009 20:02 ]

[Koffie]

Met alle respect, maar je hebt geen idee waar je mee bezig bent volgens eigen zeggen, maar gaat wel een site draaien met dergelijke aantallen.
Probeer het zou ik zeggen. Leuk dat hier iedereen op droge theorie (al dan niet icm praktijk ervaring) zit te praten maar als in de praktijk die server onderuit gaat heb je nog steeds een probleem.

Ik zeg : zet er een serve rnaast met een loadbalancer ervoor, al was het alleen maar om falen van je webserver (hard- of softwarematig) op te vangen. Als jij echt een half miljoen bezoekers op een dag naar je site denkt te krijgen zul je niet alleen een soepele webserver moeten hebben, maar ook een fallback bij storingen aan moeten kunnen.

Het niveau in dit topic is erg hoog, maar ik verwacht van TS toch ook meer eigen inzet en kennisverdieping.


Titel edit trouwens

[Reptile209]

Ben ik de enige die benieuwd is hoe de TS zijn site van 500 naar 500.000 bezoekers per dag gaat trekken? Da's nogal een uitdaging! Ga je gratis auto's weggeven ofzo?
Post eens een linkje, dan heb je meteen je eerste stress-test .

@ MAX3400 in "Dedicated webserver en 500K visitors per...": alles weer even x30 doen, het is 500k per dag, niet per maand.

[reshi]

Ik wil iedereen bedanken voor hun reacties!

Ter extra informatie: Wij verwachten zoveel mensen, omdat we voor onze site een redelijk grote actie organiseren. De bezoekers aantallen van 500.000 zijn naar ons idee een redelijke schatting.

We hebben ondertussen contact gehad met de host en hebben we getest of de server 500.00 aanvragen aan kon. Dit is volgens de host geen probleem voor de hardware van de server, wij twijfelen alleen nog over de pieken die we verwachten. Hier was geen duidelijkheid over.

Met een Gbit netwerkkaart, hoeveel mensen zou zo’n server op een piek moment aan moeten kunnen?

En inderdaad we zijn ook aan het kijken naar verschillende "fallback" options, zoals Koffie aangeeft.

[Gomez12]

Tja, ik zou gewoon even serieus kijken waar je het nu over hebt. Draai gewoon een benchmark.

Gbit netwerkkaart is leuk, maar ik gok zomaar even dat je geen Gbit aansluiting op AIX hebt.

Serieus, test het gewoon eens uit en zie wat daaruit komt.

[ReallyStupidGuy]

Mag ik vragen waarom je besluit om de server zelf te draaien en beheren als je er niet veel verstand van hebt?
Van webservers en hosting heb ik geen kaas gegeten maar als je een actie gaat opzetten waarbij je 500k bezoekers p/dag verwacht lijkt een goede bereikbaarheid op dat moment mij cruciaal. Dat moet je niet willen draaien op een eigen server waarbij je eigenlijk al doende leert. De kans dat je iets vergeet of dat er iets mis gaat is toch vrij groot.

Als je het laat hosten bij een goede host ben je een stuk zekerder en kun je eventueel zelfs afspraken maken over de bereikbaarheid.

[djluc]

Dat is het meest belangrijke bereikbaarheid is. Stel dat je harddisk kapot gaat en je ligt 3 uur plat heb je 60000 bezoekers teleurgesteld. Dat lijkt me niet de bedoeling. Dat is al bij een evenredige verdeling over 24 uur dus moet je nagaan wat dit doet als je kantooruren e.d. mee gaat rekenen.

[Marzman]

ReallyStupidGuy schreef op woensdag 09 december 2009 @ 12:29:
Mag ik vragen waarom je besluit om de server zelf te draaien en beheren als je er niet veel verstand van hebt?
Van webservers en hosting heb ik geen kaas gegeten maar als je een actie gaat opzetten waarbij je 500k bezoekers p/dag verwacht lijkt een goede bereikbaarheid op dat moment mij cruciaal. Dat moet je niet willen draaien op een eigen server waarbij je eigenlijk al doende leert. De kans dat je iets vergeet of dat er iets mis gaat is toch vrij groot.

Als je het laat hosten bij een goede host ben je een stuk zekerder en kun je eventueel zelfs afspraken maken over de bereikbaarheid.

Het is dedicated, geen colocation. Dus onderhoud en dergelijke wordt dan vaak door de host gedaan (ook niet altijd, maar in dit geval wel denk ik zoals de TS alles omschrijft). Misschien is het verstandig de vraag uit de TS dan ook bij de host weg te leggen. Laat hun een benchmarktest draaien of misschien hebben ze wel data van vergelijkbare servers van andere klanten.

[Meulugar]

Benchmark!! Meten is weten. stresstesten die hap. Maak een image. Waar draai je op ? linux? maak een image met dd_rescue icm Gzip en haal daarna een test over je server. Liever dat hij nu downgaat dan wanneer je actie begint!

[Guru Evi]

Stresstesten kun je zelf doen: JMeter, Goliath, ab...

http://www.opensourcetesting.org/performance.php

Hangt inderdaad enorm af van je scripts en de content.

Start.be draaide enkele jaren (5 jaar) geleden op een enkele Apache server, kwestie van de dynamische content statisch te maken. Een gelijkaardige Franse site had op hetzelfde moment 4 MSSQL database servers nodig die volledig overbelast waren.

[painkill]

Ik ben benieuwd welke site dit moet zijn, want zoveel bezoekers per dag, dat moest haast wel een grote actie zijn van bijvoorbeeld (als het nederlands is) grote supermarkten.

Al gok ik erop dat het een soort site zal zijn die meerdere keren per dag bezocht gaat worden door dezelfde mensen, wat dus ongeveer op 100.000 unieke bezoekers per dag uitkomt.
Maar nog steeds, de prijsvraag van Tweakers.net met sinterklaas heeft bij lange na niet 100.000 unieke views per dag gehad. Dus ik ben erg benieuwd wat hier nu achter zit.
En nu ik erover nadenk, een groot bedrijf zal het wel niet zijn, aangezien die wel professionele bedrijven inhuren..

Argh.. Die vragen toch ook altijd, ik wou dat ik ze kon oplossen...

Maar goed, je zou mij in ieder geval helpen door, in ieder geval, te zeggen wat voor soort dienst jullie aan bieden, of dan aan gaan bieden, ben namelijk zeer benieuwd.

En even over die servers, met een beetje slim programmeren is het mogelijk om 1 site met simpele content op 1 server te hosten. Dit werd vroeger eigenlijk bij alle sites gedaan. Maar sinds de komst van Java, Flash, en de intrede van design, is dit niet echt meer mogelijk. Maar word het een simpele site dan moet dit inderdaad te doen zijn. Maar zoals al eerder gezegd, BENCHMARKEN!
En ik raad aan om aan redunantie te doen, want als die HD inderdaad uitvalt dan mis je duizenden bezoekers...

[burne]

Meulugar schreef op donderdag 10 december 2009 @ 11:31:
Benchmark!! Meten is weten. stresstesten die hap.

Helemaal mee eens. Ik begon met een VM met 512M geheugen, apache en mysql. Dat leverde bij een zware belasting een maximale throughput op van 6Mbit/s bij 200 gelijktijdige bezoekers. Eerst een tijd met apache zitten emmeren. Minder modules, meer threads, maar meer dan 8Mbit/s haalde ik niet. Toen maar gekozen voor een paar uur downtijd en een overstap op FastCGI en Lighttpd. Weer veel getuned, en nu blijft de naald steken op zo'n 42Mbit/s met 500 gelijktijdige bezoekers. Voor een dynamisch gegenereerde site. De doos waar m'n benchmark op loopt zit aan een 100Mbit-verbinding, dus met statische pagina's heb ik een testprobleem, maar door even wat kennissen in te schakelen hebben we 'm inmiddels boven de 400Mbit/s gekregen met 2000 gelijktijdige bezoekers. Inmiddels cache ik ook het grootste deel van de dynamische pagina's dus die zouden bijna even ver moeten kunnen komen. (De cache checkt wel dynamisch of een pagina veranderd is, dus daar zit een mogelijke bottleneck..)

6 keer performance-winst en genoeg capaciteit voor, uitgaande van jouw pagina maar dan dynamisch, 65.000 pagina's per uur, ofwel grofweg een miljoen pageviews per dag. Statisch mag je er een 0 achterzetten.

En dat lukt enkel en alleen maar met benchmarks. Er gaat niets stuk als je een benchmark draait. Het ergste wat kan gebeuren is dat je machine dusdanig door z'n geheugen heenraakt dat 'ie gaat swappen en dat 'ie onbereikbaar lijkt, en dat is triviaal op te lossen met een reboot.

[Wolfboy]

Zolang het puur statische content is die uit het geheugen geserveert kan worden zal je grootste bottleneck in het netwerk zitten. Zodra het dynamisch is gaat dat natuurlijk minder fijn.

Maargoed... hoeveel bezoekers zou je met een gbit internet verbinding dan aan moeten kunnen? Uitgaande van 300KiB per pagina zou je dan dus 416,6 bezoekers tegelijk aan kunnen. In de praktijk zal dit iets lager liggen, maar zolang alles statisch blijft kan je van zoiets uitgaan.

Om te demonstreren dat je cpu en geheugen (bij statische content) je limiet niet zullen zijn:

Server Software:        Apache/2.2.12
Server Hostname:        localhost    
Server Port:            80           

Document Path:          /test.bin
Document Length:        307200 bytes

Concurrency Level:      50
Time taken for tests:   10.001 seconds
Complete requests:      23855         
Failed requests:        0             
Write errors:           0             
Total transferred:      7346175938 bytes
HTML transferred:       7339603163 bytes
Requests per second:    2385.30 [#/sec] (mean)
Time per request:       20.962 [ms] (mean)    
Time per request:       0.419 [ms] (mean, across all concurrent requests)
Transfer rate:          717338.66 [Kbytes/sec] received

Dat is op mijn laptopje bij een stock-install apache en een 300KB bestand met random data. Mijn laptop heeft een Core 2 Duo 2.2GHz en daarbij haal ik zo'n ~700 megabyte per seconde. 7x de snelheid van een gbit verbinding dus.

Er vanuitgaande dat er geen andere vertragende factoren zijn (of extreme pieken) zal het dus allemaal wel prima lopen. Al is een load-balancing systeem wel een goed idee, voor het geval het toch te zwaar wordt of als er wat hardware mee ophoud.

[Noork]

Wat is eigenlijk een 'bezoeker'? Bedoel je een unieke bezoeker, of gewoon een pageview?

[jvhaarst]

Heb je ook compressie op je webserver aangezet ?
Dat licht voor mij voor de hand, maar voor de TS misschien niet.

[rvrbtcpt]

Laat jmeter eens lopen. Daarmee kun je een beetje benchmarken, dat kun je zelf doen en de software kun je gratis downloaden.

[reshi]

Uiteindelijk zijn we naar een host gegaan die alle sites binnen een cluster draait, zodat er altijd uptime is en de load altijd gebalanced wordt. Dit werkt perfect voor ons.

Ik wil iedereen bedanken voor hun reacties!

[Gomez12]

reshi schreef op donderdag 07 januari 2010 @ 09:46:
Uiteindelijk zijn we naar een host gegaan die alle sites binnen een cluster draait, zodat er altijd uptime is en de load altijd gebalanced wordt. Dit werkt perfect voor ons.

Ik wil iedereen bedanken voor hun reacties!

Heb je nou ooit al eens een keer gebenchmarked of dit nu wel nodig was?

Of betaal je nu gewoon veels te veel voor dingen die je helemaal niet nodig hebt maar die wel fancy klinken?

[Verwijderd]

maar wat is die site dan ? ben wel benieuwd welke site 500k bezoekers genereerd

[Jrz]

Om welke site zou dit gaan :-)
Ben wel benieuwd hoor, want ik zou zelf ook wel 500K bezoekers willen trekken

[Verwijderd]

En toch was het een phishing website

[ Voor 88% gewijzigd door Verwijderd op 08-01-2010 16:19 ]

[Jesse]

Gomez12 schreef op donderdag 07 januari 2010 @ 13:44:
[...]

Heb je nou ooit al eens een keer gebenchmarked of dit nu wel nodig was?

Of betaal je nu gewoon veels te veel voor dingen die je helemaal niet nodig hebt maar die wel fancy klinken?

Hoeveel die nu betaalt is helemaal niet zo relevant. Als het zo goed uitkan (kosten vs baten) voor hem dan is dit met afstand de beste oplossing.

[Gomez12]

Jesse schreef op vrijdag 08 januari 2010 @ 20:52:
[...]

Hoeveel die nu betaalt is helemaal niet zo relevant. Als het zo goed uitkan (kosten vs baten) voor hem dan is dit met afstand de beste oplossing.

Het bedrag is imho idd niet relevant, wel of hij het ondertussen al eens getest heeft.

Het klinkt me nu enkel als marketing in de oren zonder een onderbouwing.

De beste oplossing zou ik het nog lang niet willen noemen zolang er geen benchmark geweest is. Het klinkt leuker, maar als dat cluster gewoon een aantal VM-bakken op 1 fysieke bak is en de loadbalancer ook enkel een VM-bak op dezelfde server is. Dan klopt het technisch, enkel is het veel duurder dan zijn huidige machine.
En presteert het waarschijnlijk net zo goed tot slechter...

Maarja, je kan niet vergelijken hoe het presteert als je de uitgangssituatie niet weet. Maarja als alleen leuker klinken al een betere oplossing is...

[Jesse]

Gomez12 schreef op vrijdag 08 januari 2010 @ 21:28:
[...]
*knip*
Maarja als alleen leuker klinken al een betere oplossing is...

Waar ik op doel is dat je moet doen waar je goed in bent. Dus als je geen (of weinig) verstand hebt van hosting maar wel een goeie hostingoplossing wil dan schakel je daar een partij voor in.

Dat dat ook weer een prutser kan zijn (bv. met een cluster gevirtualiseerd op 1 fysieke server ) is een ander verhaal. Maar daar zijn op zich geen aanwijzingen voor.

[ Voor 4% gewijzigd door Jesse op 09-01-2010 15:17 ]

[Gomez12]

Jesse schreef op zaterdag 09 januari 2010 @ 15:16:
[...]

Waar ik op doel is dat je moet doen waar je goed in bent. Dus als je geen (of weinig) verstand hebt van hosting maar wel een goeie hostingoplossing wil dan schakel je daar een partij voor in.

En van een goede partij verwacht ik een benchmark om te zien wat nodig is, het uitblijven daarvan vind ik nog steeds twijfelachtig...

Dat dat ook weer een prutser kan zijn (bv. met een cluster gevirtualiseerd op 1 fysieke server ) is een ander verhaal. Maar daar zijn op zich geen aanwijzingen voor.

Tja, als ik de volgende punten pak ( tussen haakjes is mijn mening )
- eerst van 20.000 tot 100.000 en dan zonder blikken of blozen bijstellen naar 500.000. ( blijf ik twijfelachtig vinden zolang er geen professionele partij bij zit )
- Een stresstest kost blijkbaar nogal niet wat ( oftewel er is weinig geld )
-Uiteindelijk zijn we naar een host gegaan die alle sites binnen een cluster draait, zodat er altijd uptime is en de load altijd gebalanced wordt. ( Tja 100% uptime garantie, waarom zie ik dat toch vaak niet bij de grotere professionele hosters )

Dan krijg ik toch echt meer het idee dat er gewoon voor de "goedkoopste" hoster is gegaan met de mooiste marketing praatjes. Imho kan het werken, maar misschien ook niet, feitelijk dus de beginsituatie...
Als zelfs een amazon op 99,95% blijft steken met een "iets" groter cluster dan de gemiddelde hoster, dan vraag ik me toch echt af welk cluster er 100% aanbied.

Maarja, zolang het maar voor de TS werkt denk ik dan maar.

[MMaI]

welk gedeelte jullie bij dezen natuurlijk vergeten is het feit dat volledig statische content gewoon door je client gecached wordt.
ALs je het dus hebt over 500k hits (500k bezoekers haalt ie natuurlijk nooit) waarvan 10-15% uniques met een lege cache zijn, dan heb je het maar over een belasting van 50-75k bezoekers. Gewoon een kwestie van goed configureren van expires/etags en uitschakelen van compressie. Dat laatste lijkt misschien vreemd, maar is daadwerkelijk de enige factor die zal zorgen voor een forse cpu load als er elke keer pagina compressie toegepast moet worden. Op 300kb maakt ook gzip het verschil vaak niet, en als het niet over mobiele clients gaat is de extra grootte verwaarloosbaar.

[CAPSLOCK2000]

TS heeft verstandig gedaan en het probleem overgedragen aan een bedrijf dat er wel verstand van heeft.
Daar zal vast een leuke prijs voor betaald moeten worden, maar such is life.

Hoewel de hardware het denk ik wel aan kan zal dat toch enige configuratie vereisen. 500.000 bezoekers gaat een out-of-the-box Apache ook niet leuk vinden. En zonder precies te weten hoe die website is opgebouwd wil ik eigenlijk helemaal geen harde uitspraken doen.

<intermezzo>
Ik heb wel eens een website mogen ontvangen waarvan alle plaatjes .bmp'tjes waren van meer dan 1 mb per stuk. Ingezipt blijft daar niks van over, dus het kwam gewoon per e-mail binnen, en paste vervolgens niet in de beschikbare 50 mb webruimte.
</intermezzo>

De kennis en ervaring die je voor nodig hebt doe je niet op in een weekje forums lezen. Zeker als het (zoals we vermoeden) om een of andere actie gaat. Dat moet in een keer goed zijn, want drie dagen later is het weer voorbij. Investeer je tijd of je geld, maar niet allebei. Als je de tijd niet hebt, kun je maar beter betalen.

[burne]

CAPSLOCK2000 schreef op maandag 11 januari 2010 @ 21:14:
Hoewel de hardware het denk ik wel aan kan zal dat toch enige configuratie vereisen. 500.000 bezoekers gaat een out-of-the-box Apache ook niet leuk vinden. En zonder precies te weten hoe die website is opgebouwd wil ik eigenlijk helemaal geen harde uitspraken doen.

TS heeft verder een hoop niet uit de doeken gedaan, maar laten we voor de gein eens uitgaan van een pagina van 130Kbyte en 500.000 pageviews per maand.

Over een volledige maand gemiddeld is het 200Kbit/s en zelfs met een 4:1 verhouding tussen piek en diep in de nacht is het nog altijd minder dan 1Mbit/s. Slecht 80 keer minder dan wat ik met m'n ongetuned apache zo uit de doos haalde.

Apache lacht om 500.000 pageviews per maand op een pagina van 130Kbyte met goed geschreven php etc.

[Gomez12]

burne schreef op maandag 11 januari 2010 @ 21:53:
[...]

TS heeft verder een hoop niet uit de doeken gedaan, maar laten we voor de gein eens uitgaan van een pagina van 130Kbyte en 500.000 pageviews per maand.

Over een volledige maand gemiddeld is het 200Kbit/s en zelfs met een 4:1 verhouding tussen piek en diep in de nacht is het nog altijd minder dan 1Mbit/s. Slecht 80 keer minder dan wat ik met m'n ongetuned apache zo uit de doos haalde.

Apache lacht om 500.000 pageviews per maand op een pagina van 130Kbyte met goed geschreven php etc.

Het enige lullige voor jouw redenering is dat TS wel uit de doeken heeft gedaan dat hij die 500.000 ( minimaal pageviews, hij heeft het over bezoekers maar ok ) per dag verwacht te halen en niet per maand.

Alsnog zeg ik dat apache erom lacht bij een statische page...

[burne]

Gomez12 schreef op maandag 11 januari 2010 @ 22:11:
Alsnog zeg ik dat apache erom lacht bij een statische page...

Statisch lacht apache op alles. Maar 500.000 per dag is grofweg 750Kbyte/s en m'n ongetuned apache kwam tot 8Mbyte/s, ofwel nog altijd 10 keer meer. Ik heb een rekenfout in m'n vorige post.

500.000 per dag is 5.8 pagina's per seconde, en voor een doorsnee website zou dat op een piek van rond de 25 pagina's per seconde uit gaan komen. Nog altijd niets spectaculairs voor een hedendaagse machine met een apache-uit-een-rpm erop, als je php een beetje netjes is.