Calculate the useful transfer rate your delivery window requires, then measure the complete path. Port capacity, round-trip time, TCP behaviour, storage and application processing all affect the result. Use controlled tests with realistic concurrency and repeat them through the actual application before selecting a network tier.
Turn the delivery window into a rate
Begin with an amount of useful application data and the time available to deliver it. Using decimal units, transferring 2 TB in two hours requires roughly 278 MB per second of payload, or 2.22 Gbps, before allowing for protocol overhead and interruptions. The arithmetic is a planning example, not a measured service result.
Include the transfers that overlap. A scheduled export, customer downloads and backup uploads can share resources even if their monthly totals look modest. Write a busy-period model, not only a monthly average. Specify which direction matters and whether a failed transfer must restart or can resume; that behaviour affects the amount of work the system performs.
Keep port capacity separate from useful throughput
A server port describes a link capacity. Useful throughput describes the data delivered by your application during an observed interval. Encryption, protocol framing, retransmission, storage activity and work at the receiver occupy parts of that path. A listed 10 Gbps port therefore does not establish that an application will continuously deliver 10 Gbps of payload.
IETF RFC 6349 specifically distinguishes testing the network path from examining TCP performance. Use this separation in your own diagnosis. First confirm that the endpoints and route are appropriate, then investigate the transport and application. Increasing the purchased port does not correct a receiver that writes data slowly or an application that processes one request at a time.
Understand why round-trip time matters
TCP controls how much data can remain in flight before acknowledgements return. The bandwidth-delay product gives a useful scale for this: rate multiplied by round-trip time. A hypothetical 10 Gbps path with 40 milliseconds of round-trip delay represents about 50 MB in flight. This calculation explains why latency and transport behaviour belong in high-speed planning.
The result is not an instruction to apply an arbitrary socket setting. Operating systems, congestion control, negotiated windows and the actual path influence behaviour. Verify current software documentation and inspect measurements before tuning. More parallel connections may improve aggregate throughput in some circumstances, but they can also conceal the behaviour of the individual transfer your application depends on.
Build a controlled test matrix
Use only endpoints you own or are authorised to test. Agree the test window and rate so the exercise does not disrupt normal service. Tools such as iperf3 provide configurable direction, duration and parallel streams; the official documentation defines those controls. Record the version, endpoints, route context and settings with the result so another operator can reproduce it.
Begin with a single flow, then add representative concurrency. Run both directions if the application depends on both. This illustrative matrix separates questions that a single headline result would mix together. Keep raw results privately when they reveal internal addresses or operational details, and publish only the measurements needed for the decision.
| Test | What it investigates | What it does not prove |
|---|---|---|
| One transport flow | Single-flow path behaviour | Aggregate application delivery |
| Several parallel flows | Concurrency and aggregate limits | One customer's transfer rate |
| Application transfer | Storage, protocol and software together | Performance for every dataset |
| Busy-period repeat | Variation under realistic activity | A permanent throughput guarantee |
Look at the endpoints during the test
Record CPU use, memory pressure, storage activity and error counters at both ends. A transfer result without endpoint observations may leave the real constraint invisible. Check whether one process or CPU is saturated while others are idle. Avoid changing several settings at once, because that makes it difficult to identify which adjustment helped.
Separate a memory-backed test from one that reads and writes real data. The former can help investigate the transport path; the latter reflects more of the application's job. If the results differ sharply, inspect storage and processing rather than treating the memory-backed figure as a delivery promise. Both measurements can be useful when their scope is clear.
Test the application with realistic payloads
An HTTP export, encrypted replication stream and file-transfer session have different processing patterns. Use representative file sizes, request rates and encryption settings. Include the time spent preparing data before the first byte is sent when the user waits for that step. Distinguish first-response latency from completion time instead of reporting one as the other.
Repeat the test across enough intervals to see variation, and keep a baseline before changing the configuration. For the hypothetical 2 TB export, compare the actual completion time with the two-hour window and leave margin for interruptions. Choose an improvement against the observed bottleneck rather than multiplying the port capacity without a reason.
Use the result to select a configuration
The useful output is a resource requirement with evidence: a measured payload rate, acceptable completion time, expected concurrency and a known limiting stage. Compare SwissOctet network variants against that requirement, including traffic allowance and the CPU and storage specifications. The location alone does not determine the route or end-to-end latency to every receiver.
Keep the test procedure after deployment. Reuse it when datasets grow, software changes or users move to different networks. A repeatable baseline makes a performance incident easier to diagnose and provides a sounder reason for changing a configuration than an isolated speed test or an advertised maximum.
Your practical checklist.
- Calculate payload rate from volume and deadline.
- Model overlapping transfers and direction.
- Agree authorised test endpoints and limits.
- Compare one flow, concurrency and application tests.
- Observe both endpoints while testing.
- Preserve a repeatable baseline and useful margin.
The details that matter.
Does a larger TCP window always fix a slow transfer?+
No. Diagnose the path and endpoints first. Storage, CPU, loss and application behaviour can dominate, and transport tuning must suit the actual system.
Why test a single flow and several flows?+
They answer different questions. Aggregate capacity can be higher than one transfer's rate; the application's concurrency determines which result matters.
Can I run a capacity test against any public server?+
Use endpoints you control or have permission to test. Agree duration, rate and timing so the measurement does not disrupt unrelated services.
Go to the source.
These references support the technical concepts in this guide. Follow the current documentation before changing a production system.
- IETF RFC 6349: Framework for TCP throughput testing datatracker.ietf.org
- ESnet: Invoking iperf3 software.es.net
Editorial guidance by SwissOctet. Examples are illustrative. Service specifications, available options and contractual conditions must be verified separately.