Edge Computing Realities: Reducing Latency and Data Risks in Norway

Let’s be honest for a minute. The term "Edge Computing" is currently being abused by every marketing department in the industry. They sell it as magic. It isn't. It is simply a response to physics. The speed of light is finite, and for a user in Tromsø, a round-trip to a data center in Frankfurt or Amsterdam is noticeable. It feels sluggish.

I recently worked on a project involving industrial sensor data in the Nordics. We tried piping everything to a centralized cloud provider in Ireland. The result? Latency spikes of 60-80ms and bandwidth bills that made the CFO scream. We moved the ingestion layer to local VPS instances in Oslo. Latency dropped to 4ms. The bill dropped by 60%.

This article isn't about the future. It's about what you can build right now, in March 2020, to solve latency and data sovereignty issues using standard Linux tools on local infrastructure.

The "Edge" in the Norwegian Context

With Telenor barely launching commercial 5G this month, the bandwidth pipe is getting wider, but the distance to the server hasn't changed. If your application targets Norwegian users or businesses, hosting in a massive centralized region in Germany is a strategic error. You are fighting against network hops through Denmark and Sweden.

For us, "Edge" means deploying compute resources within the country, utilizing local peering at NIX (Norwegian Internet Exchange). This keeps traffic within the national borders—crucial for compliance with the Data Inspectorate (Datatilsynet) and ensuring GDPR data minimization principles are respected.

Use Case 1: IoT Aggregation & MQTT

Sending raw telemetry data from thousands of devices directly to a central database is inefficient. The connection overhead alone will kill your throughput. The solution is an Edge Aggregator. We use a lightweight MQTT broker to terminate connections locally, filter the data, and batch-upload only the necessary anomalies to the central cloud.

We rely on Mosquitto for this. It is rock solid. Here is a production-ready `docker-compose.yml` snippet we used to deploy a secure edge broker on a CoolVDS instance:

version: '3.7'
services:
  mosquitto:
    image: eclipse-mosquitto:1.6
    ports:
      - "8883:8883" # SSL port, never use 1883 in production
    volumes:
      - ./mosquitto/config:/mosquitto/config
      - ./mosquitto/data:/mosquitto/data
      - ./certs:/mosquitto/certs
    restart: always
    ulimits:
      nofile:
        soft: 65535
        hard: 65535

Note the `ulimits`. If you forget this on a high-traffic edge node, Linux will cap your open file descriptors, and your broker will start dropping connections silently. We've seen this happen too many times.

Optimizing the Linux Kernel for High Throughput

A standard Linux distribution is tuned for a desktop or a generic file server, not for handling thousands of concurrent edge connections. If you spin up a standard instance, you will hit bottlenecks.

On our CoolVDS KVM nodes, we recommend tuning the `sysctl.conf` to handle the rapid connection cycling typical of Edge workloads. Specifically, we need to address `TIME_WAIT` sockets.

# /etc/sysctl.conf configuration for Edge nodes

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

# Reuse sockets in TIME_WAIT state for new connections
net.ipv4.tcp_tw_reuse = 1

# Fast Open reduces network latency by enabling data exchange during the initial TCP SYN
net.ipv4.tcp_fastopen = 3

# Increase the range of ephemeral ports
net.ipv4.ip_local_port_range = 1024 65535

# Max backlog for incoming connections
net.core.somaxconn = 65535

Apply these with `sysctl -p`. Without `tcp_tw_reuse`, an edge server handling rapid HTTP or MQTT requests will exhaust its ephemeral port pool in minutes, resulting in connection timeouts even if the CPU is idling.

Use Case 2: Dynamic Content Caching with Nginx

Another valid edge use case is offloading your heavy backend (like Magento or a heavy WordPress site) by caching dynamic content closer to the user. Instead of every request hitting your database in a different country, the local edge node serves a cached copy.

We use Nginx with `fastcgi_cache` or `proxy_cache`. The key is to define a cache path on a fast disk. CoolVDS provides NVMe storage, which is critical here. Traditional spinning rust (HDD) cannot handle the random I/O of a high-traffic cache.

# Nginx Config snippet for Edge Caching

proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=my_edge_cache:100m max_size=10g inactive=60m use_temp_path=off;

server {
    listen 443 ssl http2;
    server_name edge-node-oslo.example.com;

    # SSL configuration omitted for brevity

    location / {
        proxy_cache my_edge_cache;
        proxy_cache_revalidate on;
        proxy_cache_min_uses 3;
        proxy_cache_use_stale error timeout updating http_500 http_502 http_503 http_504;
        proxy_cache_background_update on;
        
        proxy_pass http://origin_backend_cluster;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

Pro Tip: The `proxy_cache_use_stale` directive is a lifesaver. If your main backend goes down or the link between Norway and the continent is saturated, your edge node will continue serving the last known good version of the site. It turns a fatal outage into a minor inconvenience.

Why Bare Metal/VPS beats "Serverless" at the Edge

There is a trend to use "Serverless functions" for edge logic. In 2020, this is still often a trap for performance-critical apps. The "cold start" problem—where a function takes 200-500ms to spin up—negates the latency benefit of being close to the user.

Running a persistent container or a daemon on a KVM VPS guarantees that your memory is hot and your application is ready. For strict latency requirements (under 50ms), a running process on CoolVDS always beats a triggered function.

Conclusion

Edge computing isn't about replacing the cloud; it's about efficiency. It's about ensuring that a request from Bergen doesn't travel to Frankfurt just to validate a JWT token or cache a JPEG. By utilizing local NVMe storage and properly tuned Linux kernels within Norway, you reduce latency, improve user experience, and keep data within the jurisdiction.

Don't let network physics kill your application's performance. Deploy a test instance on CoolVDS in Oslo today and see what single-digit latency actually looks like.