You are losing 30% of your traffic at the handshake.

I looked at a client's access.log yesterday. They were running a REST API for a mobile app targeting the Scandinavian market. Their code was optimized Node.js, their database had proper indexing, yet their Time-To-First-Byte (TTFB) averaged 400ms. In the world of mobile connectivity—where 3G is still a reality for many commuters on the T-banen—that overhead is a death sentence.

The culprit wasn't the application logic. It was a default Nginx configuration and a Linux kernel tuned for 2010 file serving, not 2015 high-concurrency API traffic. If you think spinning up a standard AWS instance or a generic VPS makes you production-ready, you are mistaken. You need to tune the metal.

1. The Hardware Bottleneck: It's Not Just RAM

Most developers throw RAM at the problem. But an API Gateway is rarely memory-bound; it is I/O and interrupt-bound. When you have 5,000 concurrent connections, your CPU spends half its life waiting for disk I/O or handling soft interrupts.

In 2015, spinning rust (HDD) is obsolete for gateways. Even standard SSDs can choke under heavy logging and caching loads. This is why we argue for high-performance storage backends. At CoolVDS, we prioritize I/O throughput because we know that when Nginx writes to the access log, you don't want the worker process blocking.

Pro Tip: If you can't afford a high-end storage array, at least disable access logging for static assets or pipe logs to a separate syslog server to reduce disk contention.

2. The Kernel: sysctl.conf or Bust

Linux defaults are conservative. They assume you are running a mail server, not an API handling thousands of erratic mobile connections. Open your /etc/sysctl.conf. If it's empty, you are running on autopilot.

Here is the baseline configuration we apply to high-performance nodes in our Oslo datacenter:

# Increase the maximum number of open file descriptors
fs.file-max = 2097152

# Increase the size of the receive queue
net.core.netdev_max_backlog = 5000

# Increase the maximum connections in the listen queue
net.core.somaxconn = 65535

# Reuse specific TCP connections (caution with NAT)
net.ipv4.tcp_tw_reuse = 1

The net.core.somaxconn is critical. The default is often 128. If you get a burst of traffic (like a push notification going out), the 129th connection gets dropped. Users see a timeout. You lose a customer. We set this to 65k+ on CoolVDS instances by default because we assume you want to grow.

3. Nginx: Beyond worker_processes

Everyone knows to set worker_processes auto;. That’s basics. The real gains in 2015 come from keepalives and buffer sizes.

SSL handshakes are expensive. If your API is HTTPS (and it should be, especially with the Datatilsynet tightening privacy expectations), you need to reuse SSL sessions. A full handshake takes multiple round-trips. In Norway, latency to the continent can add up, but even local latency hurts.

The Configuration Block

upstream backend {
    server 127.0.0.1:8080;
    keepalive 64;
}

server {
    # ... SSL config ...
    
    location /api/ {
        proxy_pass http://backend;
        proxy_http_version 1.1;
        proxy_set_header Connection "";
        
        # Force aggressive buffering off for APIs
        proxy_buffering off;
    }

Notice proxy_buffering off;. For an API, you want the JSON sent to the client as soon as it's generated. You don't want Nginx waiting to fill a buffer. This makes the app feel "snappier" to the end-user.

4. The Geographic Reality: NIX and Peering

Latency is physics. You cannot beat the speed of light. If your servers are in Frankfurt or London, but your users are in Bergen or Trondheim, you are adding 20-40ms of round-trip time (RTT) purely on distance.

This is why hosting in Norway matters. We peer directly at the NIX (Norwegian Internet Exchange) in Oslo. When a Telenor or Altibox user hits a CoolVDS instance, the traffic stays local. It doesn't hairpin through Sweden or Germany. For an API Gateway, where a single app screen might trigger 5 or 6 requests, saving 30ms per request transforms the user experience.

5. Data Sovereignty and The "Cloud" Trap

With the Safe Harbor framework looking shaky and discussions around the new EU Data Protection Regulation heating up, knowing exactly where your data sits is becoming a legal necessity, not just a technical one. The generic "cloud" is often a black box.

A dedicated VPS in a known jurisdiction allows you to answer the hard questions from your legal team. You know the disk is in Oslo. You know the backups are in Oslo.

Summary: Speed is a Feature

You can spend months optimizing your SQL queries, but if your TCP stack is negotiating connections like it's 1999, you are wasting your time. Tune the kernel, optimize the gateway, and host near your users.

If you are tired of fighting for CPU cycles on oversold platforms, deploy a test instance on CoolVDS. We don't throttle I/O, and our kernel is ready for the heavy lifting.