OCI Network Performance Tuning

Network performance complaints on OCI almost never come down to the platform being slow. They come down to a shape that caps bandwidth lower than expected, instances placed in different domains than assumed, a load balancer sized for a fraction of the real load, or a measurement that conflates latency with application slowness. This guide walks through where OCI network performance actually comes from and the levers you can pull to improve it.

Bandwidth follows the shape

On OCI, network bandwidth scales with the compute shape, specifically with the number of cores. A small shape has a modest network maximum, and a large shape has a much higher one. This is the first thing to check when throughput disappoints, because no amount of tuning will push more traffic than the shape allows. If a workload is network bound rather than compute bound, the right move is sometimes a larger shape purely for the bandwidth, or a shape family that offers more network capacity per core.

Bare metal instances get the full network capacity of the host with no virtualization overhead, which matters for the most demanding workloads. Virtual machine shapes share host capacity but still scale predictably with size. Always read the documented maximum for the exact shape rather than assuming, because the figure varies widely across families.

Placement decides latency

Latency between two instances depends on how close they are. Within a single availability domain latency is lowest. Across availability domains in the same region it is higher but still low. Across regions it is governed by distance and the speed of light, and no configuration changes that. For latency sensitive tiers that talk to each other constantly, such as an application server and its database, keep them in the same availability domain and, where the workload demands it, in the same fault domain or even a defined placement group.

A tuning framework

Jumbo frames and the operating system

Within a VCN, OCI supports larger maximum transmission units than the standard 1500 bytes. For bulk transfers, raising the MTU reduces the number of packets and the per packet overhead, which can noticeably improve throughput for backups and database replication. The catch is consistency. Every device in the path must agree on the frame size, and a mismatch causes fragmentation or dropped packets that are worse than the default. Set it deliberately across the path or not at all.

The operating system matters too. For high bandwidth paths, especially long distance ones, the default TCP window can limit a single flow well below the available bandwidth. Tuning window scaling and socket buffers lets a flow fill the pipe. This is most visible on cross region replication, where a single stream over default settings often achieves a fraction of the link capacity.

Load balancers and throughput

A load balancer that is sized too small becomes the bottleneck no matter how fast the backends are. The flexible load balancer shape lets you set a minimum and maximum bandwidth so capacity follows demand, which is almost always the right choice for production. If you pinned a fixed bandwidth early in a project and traffic has since grown, the load balancer is a prime suspect for unexplained slowness. Our guide to load balancing options covers how to choose and size the right type.

Measuring honestly

Most performance investigations go wrong at measurement. Application slowness gets reported as a network problem when the real cause is a slow query or a saturated backend. Before tuning the network, separate the layers. Measure raw throughput and latency between hosts with a controlled tool, and compare it to what the application experiences. If the raw network numbers are healthy and the application is slow, the network is not your problem. When the numbers do point at the network, change one variable at a time and remeasure, because stacking several changes at once tells you nothing about which one helped. The troubleshooting guide walks through isolating the layer that is actually slow.

Throughput versus latency

It helps to separate two things people lump together as speed. Throughput is how much data the path can move per second, and latency is how long a single round trip takes. A path can have enormous throughput and still feel slow if latency is high and the application waits for many small round trips. Conversely a low latency path can still bottleneck a bulk transfer if throughput is capped by the shape. Knowing which one your workload is sensitive to tells you which lever to pull. Bulk transfers, backups and replication care about throughput. Chatty applications that issue many small requests care about latency, and for those the answer is placement and reducing round trips, not a bigger pipe.

A practical example is a backup that runs slowly across regions. The instinct is to assume the link is too small, but if the backup uses a single stream over default operating system settings, the limit is often the TCP window rather than the bandwidth. Parallelising the transfer into multiple streams, or tuning the window, frequently multiplies throughput on the same link. Diagnose which dimension is the constraint before spending money on a larger shape that does not address the real limit.

Load balancers, gateways and the path

Performance is a property of the whole path, not of any single component, so a fast instance behind an undersized load balancer is still slow. The flexible load balancer shape removes the most common bottleneck by scaling bandwidth between a minimum and a maximum you set, so capacity follows demand rather than capping it at a value chosen early in a project. Gateways matter too. Traffic that traverses a NAT gateway or a network firewall passes through a component with its own throughput characteristics, so for high volume flows confirm that an inline appliance is not the limiting factor. When you insert inspection into a path, you are trading some performance for security, and that trade should be a deliberate choice rather than a surprise discovered under load.

This is why end to end measurement matters more than component specifications. A shape might document a high network maximum, and a load balancer might be sized generously, but if a flow passes through an inline appliance sized for a fraction of the traffic, the appliance sets the ceiling. Map the full path, identify every device a flow passes through, and size each one for the traffic it will actually carry.

Building a repeatable performance baseline

The single most useful habit is to establish a baseline you can return to. Before a workload goes live, measure raw throughput and latency between the relevant hosts under controlled conditions and record the numbers. When someone later reports that the network is slow, you have a reference point that tells you whether performance actually changed or whether the application is the cause. Without a baseline, every performance investigation starts from zero and tends to end in guesswork. With one, you can often answer the question in minutes by repeating the same measurement and comparing.

Performance and cost together

Bigger shapes and larger load balancers cost more, so performance tuning is also a cost conversation. The goal is not maximum capacity, it is enough capacity at predictable latency for the workload, sized to real demand rather than to a guess. Pair this guide with networking cost considerations so you tune for the right balance, and see the complete networking guide for how performance fits the wider design. When a workload has to perform to a number, our OCI networking solution includes the measurement and tuning work to get it there.