Fiber vs. Gin vs. Go (stdlib): Performance (Latency - Throughput - Saturation - Availability)

Summary

In this video, the presenter compares the performance of the Fiber and Gin HTTP frameworks against Go's standard library, particularly focusing on the enhancements made in Go 1.22. By deploying these frameworks in a Kubernetes cluster and generating traffic, the test reveals that Fiber excels in resource efficiency and latency, handling up to 20,000 requests per second. Meanwhile, Gin struggles with higher memory usage and client latency, managing only 15,000 requests per second. The findings highlight the improved capabilities of Go's standard library, suggesting it as a viable option for REST API development.

Takeaways

• 🚀 In this video, the performance of the Fiber and Gin HTTP frameworks is compared against the Go standard library, particularly the updated multiplexer in Go 1.22.
• ⚙️ The test involves deploying applications to a Kubernetes cluster and measuring CPU and memory usage using Prometheus, with results visualized in Grafana.
• 📊 Client-side latency and the number of requests per second that each framework can handle are also evaluated during the tests.
• 🌐 A production-ready Kubernetes cluster was created on AWS with m6a.4xlarge instance types to facilitate the tests.
• 🔄 Before Go 1.22, developing REST APIs with the Go standard library was challenging due to limited multiplexer capabilities, leading developers to use third-party libraries.
• 📉 The Gin framework consumes more memory and CPU compared to the standard library and Fiber, showing higher latency in serving requests.
• 🌟 Fiber emerges as the most efficient framework, using less CPU and memory with lower latency compared to Gin and the standard library.
• ⚠️ Fiber is based on the Fasthttp framework, which is non-standard and primarily optimized for speed; it may not be suitable for all use cases.
• ⏳ During the test, Gin hit the Kubernetes pod limit first, causing performance issues and increased latency due to throttling.
• 🔍 The standard library and Fiber also faced limitations, with Fiber handling up to 20,000 requests per second before performance degradation occurred.

Q & A

What is the main purpose of the video?

The video aims to compare the Fiber and Gin HTTP frameworks with the Go standard library, particularly focusing on the improvements introduced in Go version 1.22.

How were the tests conducted in the video?

The tests involved deploying applications to a Kubernetes cluster on AWS, measuring CPU and memory usage with Prometheus, and visualizing results in Grafana.

What key metrics were analyzed during the test?

The key metrics analyzed included client-side latency and the number of requests per second each framework could handle.

What was the setup for the Kubernetes cluster used in the test?

A production-ready Kubernetes cluster was created in AWS using m6a.4xlarge instance types.

What challenges did developers face before Go 1.22 when using the standard library?

Developers found it difficult to develop REST APIs with the Go standard library because the HTTP request multiplexer did not support mapping URI patterns with HTTP verbs.

How did the performance of Fiber compare to Gin and the Go standard library?

Fiber outperformed both Gin and the Go standard library, using less CPU and memory and having lower latency, while Gin had the highest latency and resource consumption.

What request-per-second limits were observed for each framework?

Gin handled about 15,000 requests per second, the standard library managed around 17,000, and Fiber reached approximately 20,000 requests per second before performance degradation occurred.

What does the speaker recommend for developers building web applications in Go?

The speaker recommends using the Go standard library for most web or REST applications, as it now includes the necessary features for effective development.

What is the significance of throttling observed in the tests?

Throttling indicates that the applications reached their resource limits defined in Kubernetes, affecting their performance and increasing latency.

What did the speaker mention about Fiber's reliance on Fasthttp?

The speaker noted that Fiber is based on the Fasthttp framework, which is optimized for speed in specific scenarios but is not recommended as a default choice due to its non-standard nature and associated risks.