In many industries, “real-time” is a flexible goal; however, in digital advertising, it’s an absolute law, driven by a process called Real-Time Bidding (RTB). RTB is a high-speed, programmatic auction that decides which ad to show a user in the time it takes a webpage to load. This entire transaction—receiving the request, analyzing user data, running the auction, and returning the winning ad—must be completed in 100 to 150 milliseconds. That isn’t an average; it’s the hard cutoff. A single millisecond late means the auction is lost and the transaction fails.

In this environment, “fast” isn’t good enough. You need guaranteed performance, which is precisely why public cloud platforms are typically not recommended. The potential “noisy neighbor” problem, variable network jitter, and—most critically—throttled storage I/O can introduce too much latency. You can’t win an auction where every microsecond counts when you’re paying for “Provisioned IOPS” and sharing a storage controller with a thousand other tenants.

However, there is a solution to this problem. Proxmox VE on bare metal. It provides the flexibility of a cloud-native environment, but with the raw, uncontended, single-tenant hardware you need to ensure optimal performance. But just installing Proxmox isn’t enough. You must eliminate every source of latency, and this guide offers some key infrastructure tips to tune your Proxmox environment so it can meet the demands.

Why Bare Metal Servers?

Your RTB platform must run on dedicated bare metal. There is no other option for a high-performance, high-frequency bidding application with near-zero latency.

CPU: Public cloud VMs are subject to CPU steal time, where the hypervisor preempts the vCPU for other tenants. Bare metal guarantees 0% steal time, providing 100% of CPU cycles for deterministic p99 latency.

I/O: Cloud storage (e.g., EBS) is throttled, metered, and subject to “noisy neighbor” contention. This creates an unpredictable bottleneck for high-throughput databases (Aerospike, ScyllaDB). Bare metal provides direct, uncontended access to local physical NVMe, delivering maximum predictable IOPS.
Network: Public cloud networking abstracts control and imposes per-GB egress fees and per-hour charges for virtual appliances (e.g., ELBs, NAT Gateways). Bare metal provides full, line-rate throughput (10/25Gbps+) and direct control over the physical NIC, Linux bridge, and kernel networking stack, enabling dedicated VLANs for backend traffic.

NVMe Storage Recommended

For the responsiveness needed by an RTB application, there is only one type of storage you should consider, and that is NVMe solid-state storage. This does add additional cost to your bare metal options, but it’s essential to get the minimum latency needed.

SATA SSDs: Unacceptable for an RTB workload. The bottleneck is the 6Gbps SATA protocol, a high-latency, single-queue (NCQ depth 32) interface designed for spinning media. It cannot service the concurrent I/O required by a bidding database.

SAS SSDs: A marginal improvement, but still adds latency by routing I/O through a storage controller (HBA) and its associated protocol overhead.

NVMe SSDs: The required standard. NVMe bypasses the legacy storage stack entirely, interfacing directly with the CPU over the PCIe bus. This provides a massively parallel, low-latency path (up to 65,536 I/O queues) essential for the thousands of concurrent database reads/writes characteristic of an RTB auction.
For an RTB database that is handling thousands of parallel read/write requests per second, the massive parallelism and low latency of NVMe are essential.

Proxmox Storage Configuration for RTB

Your goal is maximum I/O performance and low-latency writes, therefore its essential to configure your storage layer correctly. This is how we recommend you set up the storage for RTB:

File System: Use ZFS for its copy-on-write (CoW) integrity and ARC (Adaptive Replacement Cache).

VM Pool Layout: Create a RAID 10 equivalent, a stripe of mirror vdevs using 6-8 enterprise NVMe drives. This layout provides the highest write IOPS (no parity/RMW penalty) and low latency, which is essential for database workloads.

ZIL/SLOG Tuning: Do not use a separate SLOG device (Separate Log). With an all-NVMe pool, the main pool’s vdevs are already fast enough to service ZIL (ZFS Intent Log) sync writes with low latency. A dedicated SLOG adds unnecessary complexity and cost.

Host Boot Pool: Use 2x SATA SSDs in a ZFS mirror vdev. This provides redundancy for the Proxmox host OS and segregates host I/O, dedicating 100% of the NVMe pool’s IOPS to guest VMs.

CPU, Memory, and Infrastructure Tuning

The entire bare metal platform needs to be tuned for RTB workloads. Here are our recommendations and best practices to get your server working at its full capability.

CPU Configuration

  • Hardware: You need a balance of high core count and high clock speed. An AMD EPYC or Intel Xeon Scalable processor is the standard.
  • Host CPU Governor: The default Linux CPU governor (ondemand or schedutil) tries to save power by scaling down CPU frequency. Set the governor to performance. This forces all CPU cores to run at their maximum frequency, all the time.
  • CPU Pinning (Affinity): This is an advanced KVM trick. Assign your database VM a set number of vCPUs (e.g., 16) and then pin them to a specific range of physical CPU cores (e.g., cores 16-31). This ensures that VM has exclusive, dedicated access to those cores, eliminating scheduler latency.

Memory Tuning

  • Hardware: Use the fastest ECC DDR5 (or DDR4) RAM your server supports.
  • Guest Tuning: Your RTB database (Aerospike, Redis, etc.) likely uses a massive amount of RAM for its in-memory index. By default, the OS uses 4KB memory pages. Configure your database VM to use Huge Pages (e.g., 2MB or 1GB). This reduces the number of memory addresses the CPU has to manage, which in turn reduces TLB (Translation Lookaside Buffer) misses. This is a well-known trick that shaves microseconds off every single database lookup.

Network Infrastructure

  • Hardware: 10Gbps SFP+ is your absolute minimum. For a high-throughput platform, 25Gbps SFP28 is the modern standard.
  • Network Segmentation: Use VLANs to isolate traffic. This isn’t just for security; it’s for performance.
  • Jumbo Frames (MTU 9000): On a private backend VLAN, enable Jumbo Frames. This increases the packet size from 1500 bytes to 9000 bytes, reducing the number of packets your server has to process for large user-profile data transfers, lowering CPU overhead, and improving throughput.

LXC Containers + KVM

Proxmox gives you the unique ability to run both lightweight containers (LXC) and full VMs (KVM) on the same host. This is the ideal and preferred architecture for an RTB platform.

  • Use LXC Containers for Your Bidders: Your bidding application is likely a small, stateless microservice. Running it in an LXC container is far more efficient than a full VM. It shares the host kernel, has near-zero overhead, and can be spun up or down in seconds. You can run dozens of bidders on a single host.
  • Use a KVM Virtual Machine for Your Database: Your database (Aerospike, ScyllaDB, etc.) is the heart of your platform. It needs strong resource isolation. By placing it in a KVM virtual machine, you can dedicate and pin its CPU cores, allocate it a block of RAM (with Huge Pages), and give it dedicated access to the NVMe storage pool.

This hybrid model gives you the density and speed of containers for your app tier and the isolated, guaranteed performance of a VM for your data tier.

Proxmox: Build for Purpose

The public cloud introduces non-deterministic latency through CPU steal, I/O throttling, and network abstraction, making it unsuitable for an RTB workload. An RTB platform demands a purpose-built, low-latency stack. This stack must be founded on bare metal to guarantee 0% CPU steal and uncontended, line-rate network I/O.
Storage requires a local all-NVMe ZFS pool, configured as a RAID 10 (striped mirrors), to ensure maximum IOPS and bypass storage bottlenecks. This hardware is best managed by a tuned Proxmox environment, which can utilize both lightweight LXC containers and KVMs to minimize virtualization overhead.

Atlantic.Net provides the high-performance bare metal, global data center footprint, and 24/7 technical support required for these high-frequency workloads.

Would you like to discuss specific bare metal configurations for your RTB platform? Reach out to the team now.