Alle artikelen

De meeste serverdimensionering gaat op een van twee manieren mis: je betaalt voor cores die een jaar lang op 3% stationair draaien, of je ontdekt bij livegang dat de hot set van de database niet in het RAM past. Beide fouten komen voort uit het overslaan van dezelfde stap: dimensioneren vanuit de workload in plaats van vanuit een prijslijst. Deze gids geeft je de methode (basislijn, marge, groei), de per-workload vuistregels voor CPU, RAM, opslag en bandbreedte, en het eerlijke antwoord op de vraag wanneer je moet opschalen versus uitschalen.

Een gameserver is een single-threaded simulatielus op een vaste klok, en staat of valt dus met snelheid per core en gelijkmatige timing, niet met het aantal cores. Een gedeelde VPS zet de scheduler van een hypervisor tussen die lus en de CPU, en die jitter zie je terug als gemiste ticks. Bare metal haalt die laag weg. Dit overzichtsartikel zet bare metal tegenover een VPS en beheerde gamepanels, legt uit waarom klokfrequentie wint van coreaantal, geeft echte RAM-cijfers voor Minecraft, Rust, ARK, Palworld, Valheim en CS2, behandelt opslag en de DDoS-realiteit, het zelf draaien van Pterodactyl of de Pelican-fork ervan, en de eerlijke gevallen waarin een VPS nog steeds de juiste keuze is.

Ping is maar een deel van wat een speler voelt. Eén round trip loopt langs input sampling, de last mile, transit en peering, een wachtrij op de server en het wachten op de volgende simulatietick voordat de wereld ook maar reageert. Deze gids laat zien waar gevoelde vertraging vandaan komt, hoe tick rate en netcode het beeld veranderen, waarom jitter en packet loss meer pijn doen dan een stabiele hogere ping, en welke knop een host het meest in handen heeft: de server dicht bij de spelers zetten, op hardware die zijn tick rate vasthoudt.

Bare metal wint op de twee getallen die bepalen of een gameserver goed aanvoelt: de worst-case ticktijd en de worst-case latency. Een single-tenant VM op hardware die je zelf beheert, komt dicht in de buurt. Bij een overboekte multi-tenant VPS valt fixed-tick simulatie uit elkaar, want een vCPU die een paar milliseconden te laat wordt ingepland, is een gemiste tick die elke speler ziet als rubberbanding. Deze gids behandelt wat een hypervisor toevoegt aan een tick-loop, waarom de 95e-percentiel ticktijd belangrijker is dan de gemiddelde doorvoer, hoe je steal time en MSPT op je eigen server meet, en wanneer een VM nog steeds de juiste keuze is.

Tussen een futuresplatform en een matching engine zitten drie afzonderlijke latencies, en maar één daarvan is een hostingkeuze. Deze gids haalt ze uit elkaar en geeft daarna de cijfers die we vanuit onze eigen faciliteit in Chicago hebben gemeten naar de broker-gateways waar een NinjaTrader- of Tradovate-setup verbinding mee maakt: 0.2 ms naar de marktdata-gateway van Rithmic, onder 1 ms naar de order-gateway daarvan, ongeveer 3 ms naar die van CQG. De vraag die daarop volgt, is eigenlijk niet "VPS of dedicated". Beide staan in dezelfde stad en overbruggen dezelfde afstand, dus geen van de twee staat ergens dichter bij. Wat verschilt, is wie er nog meer tijd op de CPU inplant terwijl je strategie een berekening probeert af te ronden. Dat is een vraag over belasting, niet over milliseconden op een kaart.