Improve tracker performance by adjusting docker network configuration

[josecelano]

Relates to: #26

Context

While monitoring the live demo of the tracker, I noticed timeouts reported by external services like [newtrackon.com](https://newtrackon.com). Initially, I suspected packet loss due to these timeouts. However, further investigation revealed that packet loss is not the issue, as the socket receives traffic without any buffer overflows or errors.

netstat -su
IcmpMsg:
    InType3: 970
    OutType3: 66126
Udp:
    63062 packets received
    189025 packets to unknown port received
    0 packet receive errors
    65136 packets sent
    0 receive buffer errors
    0 send buffer errors
UdpLite:
IpExt:
    OutMcastPkts: 8
    InOctets: 3395713873
    OutOctets: 6890614661
    OutMcastOctets: 320
    InNoECTPkts: 34320131
    InECT1Pkts: 391
    InECT0Pkts: 1816
    InCEPkts: 32
MPTcpExt:

The root cause appears to be related to performance. The server is too small, or we are not taking advantage of the server resources. since we are not using 100% of the servers resources (see Digotal Ocean monitoring graphs below) I think one of the causes could be the overhead introduced by Docker, specifically when using the default bridge network mode. docker-proxy, which handles the port forwarding in bridge networks, is known to impact UDP performance, particularly for high-throughput applications like a BitTorrent tracker.

Potential Solutions

1. Switch to Host Networking Mode
   Reconfigure the tracker container to use Docker's --network=host mode. This eliminates the need for docker-proxy, reducing latency and improving performance, as the container will directly use the host's network stack.

   Pros:

   • Improved UDP packet handling and lower latency.
   • No additional NAT or routing overhead.
   • Simplifies debugging and packet inspection.

   Cons:

   • Exposes all container ports to the host, which requires careful port management to avoid conflicts.

2. Optimize Existing Docker Network Configuration
   If using host networking is not feasible, optimize the current Docker network setup by:

   • Disabling userland-proxy in Docker's configuration.
   • Increasing UDP buffer sizes and kernel parameters for the host system.
   • Considering alternative network modes like macvlan for more direct network access.

   Pros:

   • Retains Docker's flexibility and isolation.
   • Allows fine-tuning without completely changing the networking mode.

   Cons:

   • Requires more complex setup and testing.
   • May not achieve the same performance gains as host networking.

3. Evaluate Docker’s Role
   Given the potential overhead introduced by Docker, consider whether Docker is the best tool for deploying the tracker in high-performance scenarios. Running the tracker directly on the host without containerization could provide better performance at the cost of losing Docker's convenience and isolation.

Action Items

• Test the tracker with --network=host mode and compare performance metrics (e.g., response time, throughput) against the current setup.
• Evaluate the feasibility of optimizing the existing Docker network configuration for the tracker.
• Document the findings and decide on the best course of action to improve the performance of the live demo.

References

• Docker Networking Performance

Links

• How I improved UDP Server’s processing performance from 900 msg/sec to 9000 msg/sec

Droplet monitoring