netcup VPS 1000 G12 benchmarked: how fast is it really?

The VPS 1000 G12 is netcup’s entry-level VPS and the server most Serverküche recipes run on. But how fast is it really? We measured it thoroughly with standard tools – and show you the commands you can use to check your own server against it.

What are we measuring?

We benchmark the four things that matter in everyday self-hosting: CPU, memory, NVMe disk and network – each with established open-source tools (sysbench, fio, 7z, openssl, curl). All figures below come from a real VPS 1000 G12 on Debian 13. The test machine: AMD EPYC-Genoa, 4 vCore, 8 GB RAM, 256 GB NVMe.

The key figures at a glance:

Quick assessment: for an entry-level VPS these are consistently strong figures – especially the NVMe disk and the network play well above what you’d expect from the cheapest plan. But the context matters: a VPS shares the physical CPU with other customers (shared vCores). Your figures can differ depending on the neighbors’ load – how you spot that is in “When things go wrong”.

Prerequisites

• A netcup server, e.g. your first VPS, with SSH access.

• The benchmark tools. All are in the Debian package sources:

  Terminal

  sudo apt update
  sudo apt install -y sysbench fio p7zip-full

• Some free storage space (the disk tests write a few GB temporarily) and ideally no production load during the measurement.

Step by step

Step 1: Size up the server

Before you measure, look at what you’re dealing with:

grep -m1 "model name" /proc/cpuinfo && nproc && free -h

model name : AMD EPYC-Genoa Processor
4
               total        used        free      shared  buff/cache   available
Mem:           7.8Gi       689Mi       3.0Gi       656Ki       4.3Gi       7.1Gi

Four vCores on an AMD EPYC-Genoa (netcup’s current G12 generation) and 8 GB RAM. Also take a look at the steal time – the percentage the CPU “waits” because a neighbor on the same host is computing:

vmstat 1 3

In the st column (far right) it should ideally read 0. For us it was 0 over the whole test – no noticeable neighbor influence. High, persistent steal values would be the sign of an oversubscribed host.

Step 2: CPU

sysbench computes prime numbers – once on one core, once on all four:

sysbench cpu --cpu-max-prime=20000 --threads=1 run
sysbench cpu --cpu-max-prime=20000 --threads=4 run

1 Thread:   events per second:  1494.66
4 Threads:  events per second:  5973.69

Two things are remarkable here: the solid single-thread performance (Genoa cores are fast) and the almost perfect scaling – 4 threads deliver 3.996× a single one. That means: at the time of measurement, the four vCores were fully available, without neighbors siphoning off compute time.

A second, practical CPU test is the built-in 7-Zip benchmark (compression, uses all cores):

7z b

Tot:  ...  27425  (MIPS total)

7z b measures compression and decompression separately (each its own line) and combines both in the Tot: line into an overall rating – that’s the roughly 27,400 MIPS. A good reference figure to compare the VPS with other 7-Zip results online. And because encryption runs everywhere (HTTPS, backups, VPN), the AES performance with hardware acceleration (AES-NI):

openssl speed -evp aes-256-gcm

type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes  16384 bytes
AES-256-GCM      89283.37k   343370.05k  1270428.16k  3164995.93k  7671136.75k  8464845.66k

openssl speed measures single-threaded by default – so the figure applies to one core. For the throughput across all cores you append -multi $(nproc). In our run a single core reached about 7.7 GB/s (7,671,136 k) on the 8 KB blocks. TLS is thus never the bottleneck on this processor anyway.

Step 3: Memory

sysbench writes a large block repeatedly through RAM and measures the throughput:

sysbench memory --memory-block-size=1M --memory-total-size=30G --threads=4 run

30720.00 MiB transferred (28727.21 MiB/sec)

Around 30 GB/s – plenty for databases, caches (Redis/Valkey) and everything that keeps many small objects in memory. RAM on this plan is, in our experience, limited more by quantity (8 GB) than by throughput.

Step 4: NVMe disk

Here the wheat separates from the chaff – the disk is the actual bottleneck for most self-hosted apps. fio measures realistically when you bypass the page cache with --direct=1 (otherwise you measure RAM, not the disk). First the 4K random IOPS decisive for databases:

# Read (4K random read)
fio --name=rr --ioengine=libaio --direct=1 --rw=randread --bs=4k \
  --numjobs=4 --iodepth=32 --size=512M --runtime=20 --time_based --group_reporting

# Write (4K random write) – same command, only --rw=randwrite
fio --name=rw --ioengine=libaio --direct=1 --rw=randwrite --bs=4k \
  --numjobs=4 --iodepth=32 --size=512M --runtime=20 --time_based --group_reporting

read:  IOPS=101k, BW=394MiB/s
write: IOPS=67.0k, BW=262MiB/s

101,000 read and 67,000 write IOPS at 4K – that’s real NVMe level and the reason why Nextcloud, databases or Paperless feel noticeably smooth on this VPS. And the sequential throughput (large files, backups, video):

# Read (sequential)
fio --name=sr --ioengine=libaio --direct=1 --rw=read --bs=1M \
  --numjobs=1 --iodepth=16 --size=2G --runtime=15 --time_based

# Write (sequential) – same command, only --rw=write
fio --name=sw --ioengine=libaio --direct=1 --rw=write --bs=1M \
  --numjobs=1 --iodepth=16 --size=2G --runtime=15 --time_based

READ:  bw=4123MiB/s (4.3 GB/s)
WRITE: bw=2937MiB/s (3.1 GB/s)

4.3 GB/s reading, 3.1 GB/s writing. A restic backup or a large docker pull is thus done in seconds.

Step 5: Network

For throughput, you download a large test file from a well-connected server. We take the Hetzner speed test in Falkenstein (Germany):

curl -o /dev/null -w "%{speed_download} B/s in %{time_total}s\n" \
  https://fsn1-speed.hetzner.com/1GB.bin

246095181 B/s in 4.36s

~246 MB/s, i.e. about 2 Gbit/s – 1 GB in just over four seconds. A download from the US (Ashburn) was, due to distance, at ~36 MB/s; within Europe the connection is excellent. Finally the latency:

ping -c 5 1.1.1.1

rtt min/avg/max/mdev = 12.314/12.337/12.365/0.019 ms

~12 ms to 1.1.1.1 (Cloudflare’s Anycast resolver, i.e. a nearby network node – not a purely German target), very consistent (the deviation is in the hundredths). IPv6 is active and works; a ping over IPv6 was at ~26 ms.

When things go wrong

Keeping an eye on performance

• Who is the VPS 1000 G12 enough for? For practically all the single services on this site – SSH, Traefik, Vaultwarden, Uptime Kuma, a small Nextcloud. It gets tight less at CPU or disk than at RAM: as soon as several heavy apps (Nextcloud + Immich + databases) run in parallel, an upgrade to the VPS 2000 (16 GB) is the most sensible next step.
• Watch steal time long-term. A one-off benchmark is a momentary snapshot. Whoever wants to keep an eye on performance long-term takes CPU steal, I/O and network into a Grafana dashboard – there you see creeping degradation before it hurts.
• Re-measure after changes. A server migration, a product switch or a new netcup generation changes the figures. Keep your benchmark outputs (a simple text file in the backup is enough), then you have a basis for comparison.
• Stay honest: benchmark numbers age and fluctuate. They’re an orientation, not a promise – the shared vCores mean the real performance always also depends on the neighbors on the host. For the entry-level price, though, the VPS 1000 G12 delivers a remarkably well-rounded performance.