This content is a translation and organization of the performance evaluation by the well-known performance reviewer Anton Putra Fiber vs. Gin vs. Go (stdlib): Performance (Latency – Throughput – Saturation – Availability)[1]: Performance (Latency – Throughput – Saturation – Availability), with appropriate reductions, and the relevant content and conclusions are based on the original source.
Introduction
In this video[2], we will compare Fiber and Gin, as well as the Golang standard library and the improved multiplexer introduced in Go 1.22. For testing, I will deploy these applications on Kubernetes, then use Prometheus to monitor CPU and memory usage, and visualize the results in Grafana.
We will also compare client latency and the requests per second (RPS) that each framework can handle. In this test, I increased the number of external clients to generate sufficient load, forcing Kubernetes to scale these applications. Ultimately, we will determine a clear winner.
To run this test, I created a production-grade Kubernetes cluster on AWS using the m6a.4xlarge instance type. If you want to learn more, I also have a complete course specifically for EKS beginners[3].
Framework Overview
Before Go 1.22, developing a REST API using only the Go standard library was quite challenging. One of the main reasons is that the HTTP request multiplexer in the standard library does not support mapping URI patterns to HTTP methods, which is crucial for designing RESTful resources. As a result, many developers ended up using third-party routing libraries like Gin or Fiber (as well as Gorilla Mux, Chi).
However, with Go 1.22, the standard library has become powerful enough that you no longer need additional third-party web frameworks to build REST APIs. Of course, you can still use some external middleware to improve development efficiency, but the standard library now has all the necessary features.
Testing
Now, let’s start deploying these applications to Kubernetes and let them run in an idle state for 10-15 minutes.
As we can see, the Gin framework has slightly higher memory and CPU usage, while the Go standard library has resource usage that is quite close to that of Fiber.
Formal Testing
Next, I will deploy 20 clients to generate traffic for each application and gradually increase the request load. The entire test took about 1.5 hours, which I compressed into a few minutes in the video, showing the final results at the end.
From the testing process, every 5 minutes, we will add an additional 1000 RPS load to each application. From the start, we can observe a clear trend:
- Gin consumes more CPU and memory, and has the highest client latency.
- Go standard library has resource usage close to that of Fiber, but its latency is slightly higher than Fiber.
- Fiber has the lowest CPU and memory usage, and the lowest latency, performing the best among all frameworks.
Fiber is based on the Fasthttp framework, but many people do not prefer it. Fasthttp is a non-standard HTTP implementation that primarily focuses on high-performance optimization for specific scenarios. Unless you really need its specific advantages and understand the associated risks, it is not a recommended default choice. Even the official documentation suggests that in most cases, the standard HTTP library should be used.
Pushing to the Limit
Let’s continue running the tests until all applications start to crash.
-
Gin was the first to reach the Pod resource limits set by Kubernetes, causing Kubernetes to start throttling it, which directly affected performance and increased latency. If you are running CPU-intensive applications in Kubernetes, be sure to monitor throttling.
-
From the requests per second (RPS) chart, we can see that Gin under the 2 CPU and 256MB memory Pod limit can handle a maximum of 15,000 requests.
- Next, the Go standard library also started to fail and was throttled by Kubernetes, leading to an increase in latency. Under the same configuration, it can handle a maximum of 17,000 RPS.
- Finally, Fiber also reached its limit, starting to degrade at around 20,000 RPS.
Test Result Analysis
Next, let’s take a look at the data charts for each application throughout the testing period.
- Requests per second (RPS): Shows the maximum throughput of each application.
- Client latency: Measures the response time from the client’s perspective.
- CPU usage: Visually reflects the computational resource consumption of each framework.
- Kubernetes throttling: Ideally should be 0 seconds, but since we pushed the applications to their limits, Kubernetes started throttling them.
- Memory usage: Shows the memory consumption of each application.
Ultimately, Fiber is undoubtedly the winner of this test, but it is not suitable for all scenarios. From my personal perspective, you can try using the standard library in your next Go web or REST project, as it now has all the necessary features.
Conclusion
If you have any suggestions for improvements to the source code, feel free to submit a Pull Request, and I will definitely review and test it. Also, please let me know in the comments what you would like me to test.
References[1]
Fiber vs. Gin vs. Go (stdlib): Performance (Latency – Throughput – Saturation – Availability): https://www.youtube.com/watch?v=ok5DDDNsOaQ
[2]
This video: https://www.youtube.com/watch?v=ok5DDDNsOaQ
[3]
Complete course for EKS beginners: https://www.youtube.com/watch?v=aRXg75S5DWA&list=PLiMWaCMwGJXnKY6XmeifEpjIfkWRo9v2l