10 Gbps VPS Connection: What It Really Changes

A 10 Gbps port has a theoretical throughput of 1.25 GB per second. A 50 GB dataset transfers in a little over 40 seconds in the best case, compared with more than 6 minutes on a 1 Gbps port. That figure is the ceiling of the network card, not a guarantee of end-to-end speed.

Infrawire's offers are built on this 10 Gbps connectivity. Here is what it is useful for, what can limit it in practice, and how to measure it yourself instead of relying on a sales brochure.

What 10 Gbps changes in practice

The gain shows up mainly when the network is the bottleneck. On a small brochure site, the difference between 1 and 10 Gbps is invisible: the server is limited by CPU, database or code long before bandwidth becomes an issue.

Several workloads, however, saturate a 1 Gbps link quickly:

• distribution of large files (disk images, archives, media);
• backups and restores to or from remote storage;
• database replication between two servers;
• package mirrors and container registries;
• simultaneous traffic peaks, where hundreds of clients download at the same time.

In these cases, the 10 Gbps headroom absorbs spikes without queueing on the server side. Concurrent downloads share a wider pipe, so one large transfer does not slow down everyone else.

What limits real-world throughput

A 10 Gbps port does not deliver 10 Gbps to every destination. The throughput you measure depends on the whole chain.

The remote end. If the client or the server on the other side is limited to 1 Gbps, that sets the ceiling. A user on a home connection will never pull 10 Gbps from you.

The network path. Routing between two carriers, congestion at certain hours and distance all affect the result. You can inspect connectivity from the looking glass before committing to a location.

Disk and CPU. Writing at 1.25 GB/s requires decent NVMe storage. Encrypting with TLS or SSH at that rate also loads one or more cores. A single-stream scp transfer often tops out well below the link speed.

The protocol. A single TCP flow is limited by the receive window and the round-trip time. Several parallel flows make better use of the link.

Measuring throughput with iperf3

To check what you actually get, run iperf3 between your VPS and a second machine. On Debian or Ubuntu:

Bash
1sudo apt update && sudo apt install -y iperf3

On the server side, start listening:

Bash
1iperf3 -s

From the other machine, test with four parallel streams for 30 seconds, then in the reverse direction:

Bash
1iperf3 -c IP_DU_VPS -P 4 -t 30
2iperf3 -c IP_DU_VPS -P 4 -t 30 -R

Port 5201 must be open in your firewall for the duration of the test. Close it afterwards.

On a virtual machine, ethtool does not always report the real speed of the interface:

Bash
1ethtool eth0 | grep Speed

An "Unknown!" value is common with a virtual NIC and does not indicate a problem. Trust the iperf3 result.

A few useful tuning options

At high throughput, the kernel's default TCP configuration can become too conservative. Two settings worth testing, in /etc/sysctl.d/99-network.conf:

INI
net.core.default_qdisc = fq
net.ipv4.tcp_congestion_control = bbr

Apply them with sudo sysctl --system. Measure before and after: on some paths the gain is clear, on others there is none. Do not change the rmem_max and wmem_max buffers without measuring first, because excessive values consume memory for nothing.

Choosing a VPS by workload and location

Bandwidth matters as much as the geographic position of your server relative to your users. The full catalogue is on the VPS page, and the Linux VPS range suits most transfer and hosting workloads.

A wide link also helps absorb a modest attack, but it does not replace dedicated protection. If your service is a target, port capacity alone is not enough.

For workloads that outgrow a VPS, dedicated servers give you access to entire machines. The tutorials cover network configuration and hardening for these systems.

FAQ