YARP vs Nginx Performance Showdown (Surprising Results!)

Summary

In this video, the presenter compares Yarp and Engine X as reverse proxies through performance benchmarks and ease of use. The OSI model and differences between Layer 4 and Layer 7 proxies are explained, with Yarp being a Layer 7 proxy and Engine X a Layer 4 one. The setup involves running both proxies in Docker containers for standardization and ease of use. After performance tests show Yarp outperforms Engine X in raw speed, the video highlights Yarp's strong integration with .NET features, including authentication, rate limiting, and custom middleware, making it a compelling option despite being slightly slower.

Takeaways

• 😀 Yarp and Engine X are both reverse proxies, but they operate differently at various layers of the OSI model—Yarp works at Layer 7 (Application), while Engine X works at Layer 4 (Transport).
• 🧑‍💻 Yarp allows for more advanced features at the application layer, including working with cookies and JSON Web Tokens, making it more versatile in complex scenarios.
• 🚀 Yarp is set up as a reverse proxy using Docker Compose to ensure ease of use and standardized performance testing across different environments.
• 🔧 Engine X is also tested in a Docker environment, and its configuration is essential to maximizing performance. Default settings can limit its speed.
• ⚙️ To configure Yarp, you need to add the reverse proxy to the service container, configure routes, and set up clusters with backend destinations for proxying.
• 🐳 Engine X’s Docker configuration needs to be fine-tuned by mapping the configuration file into the container, specifying upstream servers, and setting location and proxy settings.
• 💡 Both Yarp and Engine X can serve as reverse proxies in a Linux container environment for performance benchmarks, but the configuration significantly impacts results.
• 📊 Performance tests using K6 showed that Yarp handled about 21,000 requests per second with a low average response time, while Engine X handled about 9,500 requests per second with higher response times.
• ⚡ After tuning Engine X’s configuration (e.g., increasing worker processes and connections), its performance improved to 37,000 requests per second, surpassing Yarp.
• 💻 While Engine X can be faster with proper configuration, Yarp’s integration with the .NET ecosystem offers valuable features like custom middleware, authentication, and rate limiting, which may outweigh the slight performance difference.
• 🔍 Yarp’s built-in support for observability through OpenTelemetry and distributed tracing makes it easier to integrate with monitoring and debugging tools compared to Engine X.

Q & A

What is the primary difference between Yarp and EngineX?

The primary difference between Yarp and EngineX lies in the OSI layer they operate at. Yarp is a layer 7 proxy, working at the application layer, giving it more control over data like cookies and JSON web tokens. In contrast, EngineX operates at layer 4, dealing with transport protocols like TCP, making it more limited in terms of the type of data it can process.

What is the OSI model, and why is it important when comparing Yarp and EngineX?

The OSI (Open Systems Interconnection) model is a conceptual framework that describes how different layers of network protocols interact. It has seven layers, and understanding where Yarp and EngineX operate within this model helps clarify their capabilities. Yarp operates at layer 7 (application layer), offering more advanced features, while EngineX operates at layer 4 (transport layer), which is more focused on low-level data processing.

How did the author test the performance of Yarp and EngineX?

The author tested the performance of Yarp and EngineX by running a simple 'hello world' API, placing either proxy in front of it, and then conducting performance benchmarking using K6. The benchmarks involved sending requests through the proxies and measuring the number of requests per second and response times.

What were the initial benchmark results for Yarp?

In the initial benchmark, Yarp handled approximately 21,000 requests per second with an average response time of 9.5 milliseconds. The P90 and P95 metrics showed that 90% and 95% of requests were completed in 14.7 milliseconds and 15 milliseconds, respectively.

What were the initial benchmark results for EngineX?

EngineX handled approximately 9,500 requests per second, with an average response time of 21 milliseconds. The P90 and P95 metrics showed that 90% and 95% of requests were completed in 23 milliseconds and 24 milliseconds, respectively.

What factors influenced the performance of EngineX during the benchmark?

The performance of EngineX was initially slower due to using the default configuration, which had suboptimal settings for worker processes and connection limits. This limited its ability to handle requests efficiently.

How did the author improve the performance of EngineX?

The author improved the performance of EngineX by tuning the configuration. Key changes included setting the worker processes to 'auto,' increasing the available worker connections, and adjusting keep-alive values. This led to a significant improvement in performance.

What were the improved benchmark results for EngineX after configuration tuning?

After tuning the configuration, EngineX handled around 37,000 requests per second, outperforming its initial results by more than 10%. The response times also improved, with a significant reduction in latency.

What additional factors should be considered when choosing between Yarp and EngineX, aside from performance?

Aside from raw performance, the ease of integration with other .NET features is an important consideration. Yarp integrates seamlessly with .NET’s authentication, authorization, rate limiting, load balancing, and middleware capabilities, as well as observability tools like OpenTelemetry, making it a more flexible choice for .NET developers.

Why might someone choose Yarp over EngineX, despite its lower performance?

Even though Yarp is slightly slower than EngineX in raw performance, its tight integration with the .NET ecosystem and its ability to easily support advanced features like custom middleware and distributed tracing through OpenTelemetry may make it the preferred choice for developers building .NET applications.