Webserver kopen (maar welke ?)

[floorcula]

hoi allemaal, ik wil zeer binnenkort mijn eigen webservertje gaan kopen.

Momenteel heb ik een dual core strato AMD dedicated servertje maar die trekt het niet meer. (top laat een load van 9+ zien op drukke uren). De sites die ik draai zijn allemaal puur php en mysql dus de processor moet best wat rekenen. Mijn idee is ook dat door er wat geheugen in te prikken mysql wat beter can cachen. Ik heb nu zo'n 200.000 hits per dag maar hoop wel naar de 400.000 hits te gaan dus er mag wel wat groei in zitten.

Helaas heb ik nog nooit in mn leven een server gekocht en zie ik op dit moment door de bomen het bos niet meer. Was er maar zoiets als een tweakers.net server best buy guide !! Ik zat te denken aan een snelle Xeon processor, 2x 500GB (sata) schijven en 8GB intern geheugen.

Ik heb een streefbedrag van rond de 1500 euro (ex btw, meer / minder mag ook mits dat zin heeft) en daarvoor kan ik een Dell 210 server kopen met Xeon X3460 (1080 euro) maar ook een Dell 410 met Xeon L5520 (1800 euro) en eventueel later de optie er 2 extra schijven bij te plakken en een extra processor.

Ik zou het echt heel erg op prijs stellen de mening van iemand te horen die er wat meer vanaf weet. Zouden jullie voor de iets goedkopere server gaan en sneller vervangen of doe ik er beter aan om wat meer uit te geven. Zijn er eventueel alternatieven die jullie aan zouden bevelen ?

Mvg Arjen

[Predator]

Voor de prijs wat een processor maar kost neem je beter 2x een goedkope Quadcore (E55xx, bv 2Ghz).
Dan heb je 8 volwaarde CPU cores. Nadeel is dat je dan wel in de duurdere 1U server range valt bij de meeste fabrikanten omdat je met 2 cpu's zit. Die Dell R210 heeft ook maar 1 cpu slot...
Dan kom je er wellicht niet mert 1500 excl BTW.

Ik weet niet welk je OS je gaat draaien (php/mysql kan natuurlijk ook op windows). Dus je memory eisen hangen een heel stuk daar vanaf.
Als je onder linux/unix gaat draaien kom je met die 8GB wel al een heel eind.

Voor de diskaccess zou ik wel echt voor SCSI disks gaan. Tenzij je echt de diskspace nodig hebt.
Als je gewoon websites host zal dat wel goed meevallen denk ik ?
Een raidcontroller met BBWC (battery backed write cache) is zeker ook een pluspunt als je veel diskwrites hebt. Dan kan je ten volle genieten van write caching. Maar dat is meestal wel een prijzige upgrade tov de default RAID controller (en je hebt wellicht ook maar enkel RAID-1 nodig). Dus dat kan je laten vallen als de prijs te hoog wordt.

Voor de rest kijk je best eens rond naar prijzen e.d.
Kijk misschien ook eens naar supermicro. Die hebben redelijk goed geprijsde servers met 2 cpu's.

[KennieNL]

Ik wil je er wel even op wijzen als je hem in een datacenter gaat plaatsen dat er erg veel naar het stroomverbruik gekeken wordt. De X3460 heeft een TDP van 95Watt, de L3426 bijv. maar een TDP van 45Watt.

Kan je behoorlijk wat in de maandelijkse kosten schelen.


Ik weet niet of 200.000 per dag hits veel is voor de webserver die je nu hebt (geen ervaring mee), maar heb je wel eens overwogen om bepaalde elementen in je website te cache (content e.d.)? Dat kan je veel sql commandos schelen -> cpu vliegt omlaag.

Ook het optimaliseren van o.a. je mysqld kan een hoop schelen.


Just a though

[ebia]

Andere optie is nog een dedicated server erbij huren (een wat stevigere) en hierop je database hosten...

[Verwijderd]

idd ebia, heeft een vriend van mij ook:)

[GlowMouse]

200.000 hits per dag is niks; als echte tweaker kun je waarschijnlijk nog enorm veel halen uit optimalisatie.

Aan de ene kant heb je het over cpu-beperkingen ('moet best wat rekenen') aan de andere kant over geheugenproblemen ('mysql wat beter kan cashen').

Voor een goede serverkeuze heb je toch wat meer info nodig zoals wat voor soort data en hoeveel er geserveerd wordt.

[floorcula]

Hoi allemaal, alvast heel erg bedankt voor de reacties !

Predator en Kenny, ik ga zeker wat met jullie hardware advies doen! Thx ! Ik weet niet of ik budget kan vinden voor de SCSI schijfconfiguratie maar ik ga er heel serieus naar kijken!

Ebia en MorenoKroes, thx voor de tip maar ik vind het stomweg leuker om een eigen server te kopen dan er een tweede bij te huren :-)

GlowMouse en KennieNL, jullie hebben gelijk ! Er valt zeker een hoop te tweaken en daar ben ik ook al een tijdje mee bezig. Ik cache bijna de helft van alle geserveerde pagina's en heb de PHP,MySQL en Apache ook al flink onder handen genomen met best leuke resultaten. Ik geef direct toe dat er nog meer uit te persen is maar zover ben ik nog niet (ik ben wel hard aan het leren !)

Maar de ene pagina is de andere niet en ik denk dat voor mijn config (oude dual core AMD 1 GB geheugen) met mijn manier van websites maken (heel veel gepersonaliseerde informatie = veel rekenwerk en veel mysql queries) met 200.000 hits per dag met bijna 2TB aan dataverkeer per maand ik toch wel een heel klein beetje aan het randje van de hardware kom te zitten. Ik geef meteen toe dat 200.000 min of meer statische pagina's peanuts is voor zo'n machine.

GlowMouse, ik dacht dat als ik meer geheugen zou hebben mysql meer (joins) kon cachen waardoor het minder zou moeten rekenen. In deze redenering zijn cpu beperkingen en geheugenproblemen aan elkaar gerelateerd of zie ik dat verkeerd ?

Mvg Arjen

[GlowMouse]

floorcula schreef op zondag 14 februari 2010 @ 18:01:
GlowMouse, ik dacht dat als ik meer geheugen zou hebben mysql meer (joins) kon cachen waardoor het minder zou moeten rekenen. In deze redenering zijn cpu beperkingen en geheugenproblemen aan elkaar gerelateerd of zie ik dat verkeerd ?

Dat zie je helemaal fout. MySQL gebruikt geheugen alleen om minder gebruik te hoeven maken van de harddisks. Het enige dat rekenwerk kan schelen is de querycache, maar het loont vaak niet om daar meer dan een megabyte aan toe te wijzen.
Het is dus van belang te zoeken waar de problemen zich bevinden. Bij cpu-problemen scheelt een opcode cacher als APC enorm veel terwijl het maar 5min werk is om te installeren. Bij disk-problemen helpt het vaak om je goed in te lezen in het gebruik van multi-column indices. Je server moet dit makkelijk aankunnen.

[floorcula]

Ha GlowMouse,

Precies, de query cache, van de mysql website kreeg ik het idee dat dat wel eens een heel fijn ding zou zijn. Ik heb er nog niet goed mee getest maar zou het wel jammer vinden als dat heen effect zou hebben ..

Wat betreft indices en APC is dat prima advies !! Maar het rare is dat ik dit al lang en breed doe. Ik draai APC en check elke query handmatig dat mysql dit snel en met correcte indexes afhandelt. Toch is de load af en toe zo hoog dat het servertje het niet meer bij kan houden.

Maar goed, ik ga je advies ter harte nemen en de hele site nog eens nalopen. Eens kijken of ik toch nog de load drastisch omlaag kan brengen.

Arjen

[xtra]

Is beschikbaarheid nog een punt van aandacht? Bij een gehuurde server pak je bij problemen de telefoon, maar bij een eigen server moet je meteen in de auto stappen en hopen dat je vervangende onderdelen of een complete server heb liggen.
Daarom zou een tweede server minder leuk, maar uiteindelijk wel makkelijker kunnen zijn.

[GlowMouse]

floorcula schreef op zondag 14 februari 2010 @ 22:09:
Maar goed, ik ga je advies ter harte nemen en de hele site nog eens nalopen. Eens kijken of ik toch nog de load drastisch omlaag kan brengen.

Als de load hoog is, ga eens statistieken verzamelen. Wat is de bottleneck?
En bij MySQL kijk je op zo'n moment in de processlist. Die hoort vrijwel de hele tijd leeg te zijn. Zie je queries daarin meer dan eens terug, dan heb je een probleem te pakken.

[floorcula]

Hi xtra, ik heb daar aan gedacht en dat is een heel goed punt.Ik heb gelukkig een backup server waar ik gebruik van mag maken.

GlowMouse, ik ben op dit moment munin aangezet met de hoop dat dat wat hints geeft. Ik zal dat eens een paar dagen laten draaien voor een compleet beeld. Mysql processlist is leeg. Weet jij (of iemand) een betere manier om info te verzamelen ??

Iig heel erg bedankt !! Ik heb hier een hoop aan !

Arjen

[KennieNL]

Check je mysql eens voor slow queries.. en log ze eventueel (is een setting)

[cariolive23]

MySQL kan (kon?) slecht tegen veel concurrent users, kijk dus ook even hoeveel concurrent users er op jouw database zitten. PostgreSQL heeft geen enkele problemen met honderden concurrent users, dat zou een reden kunnen zijn om de boel te migreren. Mits jouw database het probleem is, anders los je dat probleem uiteraard niet op.

Ga eerst uitzoeken waar nu precies het knelpunt zit, wanneer je dat niet weet, weet je ook niet hoe je het moet oplossen. 1500 euro uitgeven voor een nieuwe server kan dan zomaar weggegooid geld zijn.

[GlowMouse]

cariolive23 schreef op vrijdag 19 februari 2010 @ 10:58:
MySQL kan (kon?) slecht tegen veel concurrent users, kijk dus ook even hoeveel concurrent users er op jouw database zitten. PostgreSQL heeft geen enkele problemen met honderden concurrent users, dat zou een reden kunnen zijn om de boel te migreren. Mits jouw database het probleem is, anders los je dat probleem uiteraard niet op.

Ga eerst uitzoeken waar nu precies het knelpunt zit, wanneer je dat niet weet, weet je ook niet hoe je het moet oplossen. 1500 euro uitgeven voor een nieuwe server kan dan zomaar weggegooid geld zijn.

Bron? Bovendien: als je bij een webapplicatie veel concurrent MySQL users hebt dan betekent dat je script niet snel genoeg is of er queries te langzaam zijn.

[Eijkb]

Waar je ook naar kunt kijken is hoeveel inkomsten (als die er al zijn) gemist worden door een trage website op de piekmomenten. Stel je hebt een website rondom een bepaald punt (voetbalwedstrijd) en die 200.000 per dag komen binnen anderhalf uur van die wedstrijd op je website praat je eigenlijk niet meer over 200k per dag. Als er dan nog 200k afhaken vanwege trage respons dan zal je budget wellicht wat hoger mogen voor een 2de of vervangende server. Maar goed, dat is dus meer een administratieve invalshoek.

[cariolive23]

GlowMouse schreef op vrijdag 19 februari 2010 @ 13:21:
[...]

Bron?

Bron: databasetest-achtvoudige-opteron.

... maar de grafiek toont een effect dat we alleen bij MySQL eerder hebben gezien: grotere drukte geeft slechtere in plaats van constante prestaties.

Linkjes naar andere tests van Tweakers waarbij zowel MySQL als PostgreSQL worden besproken, vind je in deze test. Daarin kun je ook lezen dat de MySQL-database van Tweakers al zwaar is geoptimaliseerd, dat i.t.t. de geteste PostgreSQL-database. Daar valt dus nog wel meer performance uit te slepen.

Bovendien: als je bij een webapplicatie veel concurrent MySQL users hebt dan betekent dat je script niet snel genoeg is of er queries te langzaam zijn.

Dat is nieuw, dit soort conclusies kun je absoluut niet trekken wanneer je niet weet wat voor soort queries er worden uitgevoerd. Veel concurrent users op je database, zegt alleen maar dat je veel concurrent users hebt. Het zegt niks over de snelheid van je scripts of over de snelheid van de queries, die kunnen allemaal maximaal zijn. Het kan uiteraard wel zijn dat je complexe queries uitvoert die veel tijd kosten waardoor er uiteindelijk veel concurrent users ontstaan die allemaal met complexe zaken bezig zijn.

ORM-tools willen ook nog wel eens voor verstoppingen zorgen, die kunnen overdreven veel queries naar de database sturen om hun gegevens op te vragen terwijl je dit ook met één of enkele queries zou kunnen doen.

Maar dat is allemaal gegis en zal dus niet tot een oplossing leiden: Meten is weten!

[axis]

floorcula schreef op zondag 14 februari 2010 @ 18:01:
Ebia en MorenoKroes, thx voor de tip maar ik vind het stomweg leuker om een eigen server te kopen dan er een tweede bij te huren :-)

Snap ik.. ben je zelf ook handig genoeg om alle problemen met je OS op te lossen? Voor support kun je dan niet meer bij je provider aankloppen..

Daarnaast, afhankelijk van de aard van je applicatie kun je waarschijnlijk ook op je huidige platform nog een boel performancewinst halen door te optimaliseren. En de kennis over het optimaliseren zul je uiteindelijk toch nodig hebben, is het niet uit je huidige dedicated machine dan wel op je colocated machine.

Dus investeer inderdaad eens in het opzetten van monitoring (bijvoorbeeld met SNMP en cacti), zodat je kunt zien hoeveel IOPS je disks doen, hoeveel je CPU belast is, hoeveel queries per seconde je doet met MySQL, etc.. Het zou zonde zijn als je nu investeert in een dikke xeon terwijl blijkt dat je disks de bottleneck zijn.

Als je veel objecten hebt die cachebaar zijn kan het ook nog heel erg helpen om een reverse proxy zoals squid of varnish voor je site te zetten (kan uiteraard op dezelfde machine), zodat apache zich niet bezig hoeft te houden met het spoon-feeden van clients, daar is bijvoorbeeld squid beter in. Zware webservers zoals Apache en IIS zijn een boel resources kwijt aan het openhouden van veel connecties, en daar heb je dan geen last meer van. Daarnaast kan squid dan ook cachebare objecten zoals plaatjes en stylesheets direct uit het geheugen serveren.

[ Voor 4% gewijzigd door axis op 20-02-2010 08:44 ]

[CyBeR]

axis schreef op zaterdag 20 februari 2010 @ 08:43:
[...]

Snap ik.. ben je zelf ook handig genoeg om alle problemen met je OS op te lossen? Voor support kun je dan niet meer bij je provider aankloppen..

Wel hoor, kost alleen wat maar de meeste coloboeren doen ook beheer. Of dat dan vantevoren afgesproken is of achteraf doorgefactureerd maakt ze dan niet zo uit. Moet je alleen niet bij de Leasewebs van deze wereld zitten, maar meer bij de True-achtigen.

[GlowMouse]

cariolive23 schreef op vrijdag 19 februari 2010 @ 13:50:
[...]

Bron: databasetest-achtvoudige-opteron.

Dat is nieuw, dit soort conclusies kun je absoluut niet trekken wanneer je niet weet wat voor soort queries er worden uitgevoerd. Veel concurrent users op je database, zegt alleen maar dat je veel concurrent users hebt. Het zegt niks over de snelheid van je scripts of over de snelheid van de queries, die kunnen allemaal maximaal zijn. Het kan uiteraard wel zijn dat je complexe queries uitvoert die veel tijd kosten waardoor er uiteindelijk veel concurrent users ontstaan die allemaal met complexe zaken bezig zijn.

Die problemen zijn allang verholpen met XtraDB (of in mindere mate de InnoDB plugin).\
Complexe queries horen niet thuis in een web-omgeving waar je requests zo snel mogelijk af wilt handelen, wanneer ze niet efficient mbv de juiste indices afgehandeld kunnen worden.

[cariolive23]

GlowMouse schreef op zaterdag 20 februari 2010 @ 14:50:
[...]
Die problemen zijn allang verholpen met XtraDB (of in mindere mate de InnoDB plugin).\

Ik mag het hopen, ze hebben al veel te lang bestaan.

Complexe queries horen niet thuis in een web-omgeving waar je requests zo snel mogelijk af wilt handelen, wanneer ze niet efficient mbv de juiste indices afgehandeld kunnen worden.

En noem eens één omgeving waar requests niet zo snel mogelijk moeten worden afgehandeld? Het web is niets bijzonders, het is over het algemeen alleen wat eenvoudiger wat betreft de soorten queries. Dat zorgt dus al min of meer automatisch voor eenvoudiger queries. Alleen is een query voor MySQL al vrij snel complex terwijl andere databases het nog steeds zien als een eenvoudige query. MySQL is niet al te intelligent en heeft maar een beperkt aantal mogelijkheden om queries uit te voeren. Dat is eerder een beperking dan de zogenaamde complexiteit.

Een query met een stuk of 20 inner, left en right joins en paar miljoen records, dat kan op een simpel x86 servertje binnen enkele duizendsten van een seconde worden uitgevoerd, stelt niks voor. Je moet uiteraard wel zorgen voor een correcte configuratie en de juiste indexen. En dat zijn twee punten waar het 9 van de 10 keer fout gaat, waar men nauwelijks aandacht aan besteedt.

Databases zijn werkpaarden en het maakt ze geen moer uit of dat nu voor een web-omgeving is of voor iets anders. Zet ze aan het werk en laat ze het werk voor jou doen!

En MySQL, het heeft vele beperkingen maar ook daar kun je met een goed gekozen aanpak flink wat performance eruit slepen. Je moet alleen altijd de valkuilen in de gaten houden, zodra je daar in valt, is het over en uit met de performance.

[GlowMouse]

cariolive23 schreef op zondag 21 februari 2010 @ 20:59:
[...]

En noem eens één omgeving waar requests niet zo snel mogelijk moeten worden afgehandeld?

Een situatie waarin geen sprake is van requests Verder zijn we het wel eens dat TS beter kan gaan optimaliseren. In een web-omgeving kies je al heel snel voor een extra tabel met redundante data en wat extra indices wanneer een query anders niet heel efficiënt uitgevoerd kan worden.

[CH4OS]

Ik weet niet hoe statisch die aard is van jouw caches (of hoe je ze opslaat), maar is lighttpd dan misschien voor die statische content geen betere webserver?

In sommige gevallen wil die best een groot verschil maken. (bron)

[_JGC_]

Die benchmarks zijn al iets van 4 jaar oud, daarnaast wordt Apache zeer waarschijnlijk in prefork mode getest ipv worker mode. Dan wint lighttpd het op zich al heel erg snel. Niet dat ik iets tegen lighttpd heb, ik heb het jaren geleden ook op een site met succes ingezet als vervanger voor een trage Apache.

Ik zou niet meteen gaan zoeken naar nieuwe hardware op het moment dat iets ineens trager wordt bij wat meer bezoekers.
- is er een opcode cache, zo ja, welke
- met welke instellingen draait MySQL, denk hierbij aan storage engines en de instellingen ervan
- welke storage engines gebruik je zoal, en wat voor queries gooi je hierop
- hoe is het een en ander aan apache geconfigureerd? denk hierbij aan dingen als keepalive, mod_deflate, etc.

Die eerste is bijvoorbeeld een leuke. Een tijdje geleden hadden wij problemen met xcache, en heb ik geprobeerd om eens te testen zonder xcache.10 seconden nadat ik de server zonder xcache in de loadbalancer had ingeschakeld was dat ding al niet meer te benaderen. Nou moet ik zeggen dat wij een joekel van een codebase hebben met hier en daar hele ranzige code, zonder opcode cacher serveer je dat niet concurrent aan een heleboel gebruikers, ook niet met 43 webservers.

Die 2e en 3e zijn nog leuker. Met goede tuning van je databaseserver merk je niet eens dat je code beroerd is. Ik heb een keer een module voor een CMS gebouwd wat getest is op een licht getunede MySQL met InnoDB. De code deed ranzige dingen, na profilen bleek dat 95% van een pagina werd doorgebracht in mysql_query en mysql_fetch_object. Dat profilen werd pas gedaan toen een produktiemachine zonder enige vorm van InnoDB tuning 10 seconden over een page load deed.

Die 4e is een leuk voorbeeld van overmoedig keepalive instellen. Standaard staat je keepalive timeout op iets van 15-20 seconden, soms nog langer. Heel erg leuk als je een paar clients hebt, want die kunnen dan gewoon verbonden blijven met je server tijdens het rondsurfen op je site. Als je echter veel clients hebt met Apache in prefork mode, heb je maar een beperkt aantal slots. Je kunt dan wel een 4-core of 8-core server gaan neerzetten, maar als je 500 concurrent connecties aankunt met Apache in prefork mode, en hiervan continu alle connecties in gebruik zijn dankzij keepalive, heb je die dure machine voor niks gekocht. Keepalive timeout gaat bij een beetje drukke site naar 1 of 2 seconden hier: kan de browser nog wel via 1 verbinding een heleboel plaatjes van je site downloaden, maar staat je server niet doelloos te wachten op een client die idle is.

[cariolive23]

GlowMouse schreef op zondag 21 februari 2010 @ 23:10:
[...]
In een web-omgeving kies je al heel snel voor een extra tabel met redundante data en wat extra indices wanneer een query anders niet heel efficiënt uitgevoerd kan worden.

Heel snel kiezen voor redundante data? Nou, dat zou eerder mijn laatste redmiddel zijn dan een eerste/snelle keuze. Slimme queries en goed gekozen indexen zorgen vaak voor veel meer versnellingen dan een extra tabel met redundante data. Dit is hooguit interessant voor data met complexe berekeningen die voor veel vertraging zorgt. Maar ja, je zegt net zelf al dat je geen complexe berekeningen in je SQL wilt hebben, dan speelt dit probleem toch al niet. En daarnaast zijn 9 van de 10 webtoepassingen dermate simpel dat het probleem ook al niet speelt.

Slimme queries en goede indexen, dát zorgt voor snelheid. Uiteraard met de juiste configuratie van je database, anders zijn je indexen nog steeds onbruikbaar.

[machielse]

Waarom zou je kopen als je ook voor weinig kan huren?
Ik heb inmiddels drie servers bij OVH.nl Ze hebben hun goedkoopste servers op www.isgenoeg.nl staan. Al hun sites zijn nogal knullig vertaald (zijn Fransen). Het is een gigantisch bedrijf (qua aantal servers) dat alles 100% gestandaardiseerd en geautomatiseerd heeft, waardoor ze zo scherp geprijsd kunnen zijn.
En o ja: hoe goedkoop? Vanaf 25 euro per maand voor een simpele Celeron met 2GB RAM en 500GB HD. Ik heb zelf inmiddels:
- €39/maand: Core2Quad machine met 4GB RAM voor
- €49/maand: i7 (quad core met hyperthreading) machine met 8GB RAM en 2x 500 GB (met software RAID).
- €125/maand een dual-quad-core Xeon machine met 16GB RAM en 2x 80GB SSD. Die laatste is laten we zeggen een "beest" Daar draaien m'n databases op.
Eigen servers hebben is leuk, behalve dan als er op zondagmorgen als jij met je dronken hoofd in bed ligt een hd klapt en je met een nieuwe hd (waar koop je die zondagmorgen) naar de colo moet
Succes!
PS: De meeste van OVH's machines staan in Frankrijk, in Raubaix om precies te zijn (vlak bij de belgische grens). Ping is ±14ms. Dat maakt qua latency dus niet uit (ping naar machines hier in amsterdam is ±9ms vanuit amsterdam). En OVH heeft een kantoor in Rotterdam, dus daar heb je dus ook het contract/contact mee.

[machielse]

cariolive23 schreef op maandag 22 februari 2010 @ 10:47:
[...]

Heel snel kiezen voor redundante data? Nou, dat zou eerder mijn laatste redmiddel zijn dan een eerste/snelle keuze. Slimme queries en goed gekozen indexen zorgen vaak voor veel meer versnellingen dan een extra tabel met redundante data. Dit is hooguit interessant voor data met complexe berekeningen die voor veel vertraging zorgt. Maar ja, je zegt net zelf al dat je geen complexe berekeningen in je SQL wilt hebben, dan speelt dit probleem toch al niet. En daarnaast zijn 9 van de 10 webtoepassingen dermate simpel dat het probleem ook al niet speelt.

Slimme queries en goede indexen, dát zorgt voor snelheid. Uiteraard met de juiste configuratie van je database, anders zijn je indexen nog steeds onbruikbaar.

Het verschilt gewoon van geval tot geval. Vooral als je met heel grote tabellen te maken hebt, zijn joins vaak heel slecht "performant" te krijgen. Dan kan denormalisatie enorm helpen.
Maar je moet inderdaad beginnen met indexering helemaal goed te doen. Is vaak meteen een mooie aanleiding om uit te zoeken hoe je specifieke db-server nu echt werkt (achter de schermen).
Voor bepaalde gevallen is een niet-relationele db ook een alternatief. Zo doet Google dat met BigTable.

[Aike]

machielse schreef op vrijdag 26 februari 2010 @ 14:27:
Waarom zou je kopen als je ook voor weinig kan huren?
Ik heb inmiddels drie servers bij OVH.nl Ze hebben hun goedkoopste servers op www.isgenoeg.nl staan.

Daar ben ik het mee eens, waarom kopen als je kan huren voor minder geld? Je zou zelfs 2 van die ovh-machines kunnen nemen. Heb er zelf goede ervaring mee.

[CyBeR]

Aike schreef op zondag 28 februari 2010 @ 16:57:
[...]

Daar ben ik het mee eens, waarom kopen als je kan huren voor minder geld? Je zou zelfs 2 van die ovh-machines kunnen nemen. Heb er zelf goede ervaring mee.

Omdat huren op langere termijn duurder is? En ook moet zijn, trouwens. Dat bedrijf waar je huurt moet ook geld verdienen aan hetzelfde ding als wat jij direct zou kopen. Het enige is dat je bij het kopen in één keer een bepaalde hoeveelheid uitgeeft terwijl je als je huurt meer geld uitgeeft, maar in kleinere brokjes.

[ Voor 30% gewijzigd door CyBeR op 28-02-2010 16:59 ]

[Verwijderd]

Vergelijk kosten voor:

• Optimaliseren
• Kopen van een server + hosting kosten
• Huren van een server

vs

Verwachtte opbrengst door snellere response tijd en verwachtte omzetgroei als je de 400k pages haal.


Tijd wordt soms gezien als iets dat gratis is, maar dat lijkt vaak alleen maar zo. Als je er twee weken met 1 man full time mee bezig ben kost dat al evenveel als een servertje erbij zetten. Verder: load betekent niet altijd CPU tijd, als een proces op IO wacht telt dat ook als runnable. Zelfde geldt voor swap, dat laatste kan spectaculaire load nummers opleveren van 100+.

[cariolive23]

Verwijderd schreef op maandag 01 maart 2010 @ 01:56:
Als je er twee weken met 1 man full time mee bezig ben kost dat al evenveel als een servertje erbij zetten.

Met een andere server kun je hooguit een factor 10 sneller zijn, met optimalisatie van je code kun je een factor 1000 sneller zijn. Dit geldt in elk geval voor queries, daar is een verbetering met een factor 1000 eerder regel dan uitzondering. Zeker wanneer er nog nooit een DBA aan heeft meegewerkt.

Daarnaast loop je bij migratie van server A naar server B ook nog de nodige risico's en is er sprake van downtime.