Onderwerp: Hoeveel "shared hosting accounts" op 1 VPS (1gig/1 CPU core)

Hallo,

Ik wil van resellen een stapje verder gaan een een eigen VPS huren.
Hoeveel accounts kan ik op een server met 1gb ram en 1 CPU core (2 ghz)
draaien? De accounts zullen vooral wordpress draaien en per account
zo'n 100 bezoekers per week hebben. De VPS moet dus bestand zijn
tegen zo'n 10.000 wordpress views per maand.

Bedankt

Wordpress heeft de neiging een server wat zwaar te belasten, afhankelijk van plugins. Als je deze VPS echt voor wordpress wilt inzetten dien je deze voor wordpress te optimaliseren. Wanneer dit gedaan is kun je in principe meer sites kwijt. Indicatie van exact aantal sites kan ik je niet geven helaas. Maar dat kan niemand. Tussen de 50-80 sites, zonder optimalisatie?

Met caching ben je heel veel geholpen, vaak ook bij de relatief zwaardere plugins. Maar 10000 views per maand gaat de server niet van schrikken. Blijft altijd koffiedik kijken, dus het klopt wat Ahmed zegt: precies weten doe je het nooit. Bij posts hier krijg je garantie tot aan de deur dus.

Heel erg bedankt. Ben stuk wijzer. Ik wist niet dat servers "geoptimaliseerd" konden worden voor wordpress. Ga er ff op googlen. Bedankt.

Oorspronkelijk geplaatst door gurk

Heel erg bedankt. Ben stuk wijzer. Ik wist niet dat servers "geoptimaliseerd" konden worden voor wordpress. Ga er ff op googlen. Bedankt.

Is het niet verstandiger langer gebruik te maken van je reseller pakket alvorens alles te gaan verhuizen ? In hoeverre beheer je de basis, kun je de spullen up-to-date houden etc etc ?

Oorspronkelijk geplaatst door gurk

Heel erg bedankt. Ben stuk wijzer. Ik wist niet dat servers "geoptimaliseerd" konden worden voor wordpress. Ga er ff op googlen. Bedankt.

Ieder pakket is weer anders gebouwd en vraagt weer wat anders van mysql, apache, PHP, OS, enz. Wel belangrijk om te weten wat je beheert en hoe ermee om te gaan! Snap dat je niet altijd in de gaten kan houden wat voor pakketten je klanten allemaal installeren, maar als je performance issues krijgt, is een inventarisatie en handelen naar wat geïnstalleerd is, wel verstandig

Daar is eigenlijk geen zinnig antwoord op te geven, 1 CPU core is heel weinig maar daarnaast is het natuurlijk de vraag hoe zwaar andere VPS'en die core belasten op alle vlakken en niet alleen de CPU. En de I/O is vaak de bottleneck bij een VPS en de performance hangt of staat daarbij. Hoe goedkoper de VPS, hoe waarschijnlijker dat je op een omgeving komt die al zwaar belast is en je misschien een paar honderd bezoekers/dag aankunt, terwijl je elders met dezelfde specificaties maar een minder belaste omgeving je een veelvoud van de bezoekers aankan. Vergelijk het maar met de PK's van een auto, deze zeggen eigenlijk bijna niets over hoe snel een auto is. Als je 300PK in een auto gooit van 2500kilo dan is die echt een stuk trager dan een auto van 700kilo met 100PK. En zo zijn er nog veel meer variabelen die invloed hebben, netzoals dus met een VPS.

We proberen zelf maximaal 200 sites (gemengde, eenvoudige shared hosting) per VPS te plaatsen (2-4 cores, 2-4 GB geheugen). Het hangt natuurlijk wel erg af van het soort websites, maar het geeft je een ballpark.

Oorspronkelijk geplaatst door websiteondemand

Ieder pakket is weer anders gebouwd en vraagt weer wat anders van mysql, apache, PHP, OS, enz. Wel belangrijk om te weten wat je beheert en hoe ermee om te gaan! Snap dat je niet altijd in de gaten kan houden wat voor pakketten je klanten allemaal installeren, maar als je performance issues krijgt, is een inventarisatie en handelen naar wat geïnstalleerd is, wel verstandig

Ben ik mee eens, ook is de netwerk belangrijk vaak hebben de goedkope vps geen regel bijvoorbeeld dat er geen torrent mag gebruikt worden, de in en out is heel veel dus alles gaat naar main server > vps. wat ook de ervaringen verslechterd voor de ander vps gebruikers en de 2ghz is niet zeker als de load van de server hoog is word jou 2ghz gebruikt. Dus probeer te zorgen wanneer je een vps haalt dat hij niet te vol word gestampt :P en vaker mag je meer van de cpu gebruiken.