Who is the fastest go web framework

This is a creation in Article, where the information may have evolved or changed.

A few days ago I wrote an article: The ultra-full go HTTP routing framework performance comparison, using Julien Schmidt implementation of the benchmark test framework for almost all the Go web framework of the routing function is compared. I would have thought that the performance of the Go web framework would be subject to a paragraph, until I wrote a simple code test Irsi to simulate the processing in the actual product before I discovered the Julien Schmidt test framework.

This code is like this:

12345678910111213141516171819202122

package mainimport ( Span class= "string" "FMT" "OS" "StrConv" "time" "Github.com/kataras/iris" ) func Main () {API: = Iris. New () API. Get ( "/rest/hello" , func (c *iris.) Context) {Sleeptime, _: = StrConv. Atoi (OS. Args[1 ]) if sleeptime > 0 { Time. Sleep (time. Duration (sleeptime) * Time.millisecond)}c.text ( "Hello World" )}) API. Listen ()}

When I simulate the processing time of the actual business to 10 milliseconds, I use 100 concurrency to test:
wrk -t16 -c100 -d30s http://127.0.0.1:8080/rest/hello, Iris throughput rate reached Requests/second. See my article in detail: is Iris really the fastest Golang routing framework?

Although Iris's author quickly revised it to solve the problem, it also prompted me to re-examine the Julien Schmidt test framework, prompting me to implement a framework for testing the Go Web Framework Benchmak: GO Web framework Benchmark

2016/04/12 updated: now Iris has been changed to fasthttp implementation, super good performance.

Statement
Recently, some people have accused Iris's author of "Stealing" other people's code, such as Httprouter, without claiming copyright. Basically Iris's high performance comes from the efforts of some frameworks such as Fasthttp and Httprouter, and the author's description of the IRIS project on GitHub, "the world's fastest web framework", is obviously a hate-mongering.
Although I am quite clear about the whole incident, I have no intention of joining this argument, and I created the Go Web framework benchmark to help developers evaluate the performance of each framework, rather than compete with each other and not expect to attack or belittle others with the test results of my project.

Basically the Go web framework is divided into two portals, a framework based on the standard library net/http and a framework based on the Fasthttp library. Obviously, the framework performance based on the Fasthttp library is better than the standard library, but they also have shortcomings, such as incompatible with the standard library (or not easily compatible), do not support HTTP2, etc., you have to choose the time to understand the choice.

Re-examining the Julien Schmidt test framework

If you look at the test results and implementations of the Julien Schmidt Test framework, you can see that he is testing the routing capabilities of the web framework, including parsing parameters in the path, and not testing the processing of a complete web framework (accepting connections, routing, handler processing).

Using the Go Benchmark test framework approach, he implemented N-benchmark methods by manually creating an HTTP. Request, passed to router for route processing.

And, his handler business is very simple, some handler there is no business logic, just empty method body, and some just write the parameters back to response. This does not reflect the business process of the actual product.

In the actual business, handler must include certain business processing, but also out of processing time may be from a few milliseconds to hundreds of milliseconds, some business logic is also very slow processing, such as:

• Reading data from a network connection
• Write data to the hard disk
• Accessing the database
• Accessing the cache server
• Call other services and wait for the return of the service result
• ......

If the processing time of these business logic is added, will the individual web framework benchmark be the same as the benchmark of the routing function?

Because the processing time of the route occupies a smaller proportion of the processing time in the entire Web frame, the benchmark of the actual web framework is likely to have little relation to the benchmark of the route. Even if the performance of the route is best, if the processing of handler is not well handled, the overall performance may not be particularly good.

If you want to implement a high-performance router, be sure to avoid allocating new objects when routing processing, high-performance routers have achieved 0 allocation, such as httprouter, Iris and so on.

Many of the web framework's handler processing, like the default implementation of Go, is performed in the goroutine where the connection resides, and the framework implements the Goroutine pool, which is handled by a goroutine pool of connections and handler, Avoid too much goroutine allocation and recycling, and performance may be better.

Implement a Go web Framework benchmark Library

Therefore, it is necessary to implement a new test framework (library), complete testing the performance of the web framework, including connectivity, routing, handler processing, etc., based on this, I implemented the GO Web framework benchmark.

It has the following features:

1. A/hello HTTP GET service is implemented for each web framework, which returns a hello world string. The implementation of all Web frameworks is consistent.
2. You can specify the time for business processing, such as 10 milliseconds, 100 milliseconds, 500 milliseconds, etc.
3. Automated testing

The framework does not test other features, such as post, Put, or the ability to test the parameter resolution of a route, and it is intended to compare the capabilities of each framework's processing to the business by testing the Get method.

Based on the Go web framework tested in the Julien Schmidt Test Framework, the following Web framework was tested in addition to lion,fasthttp.

• Default HTTP
• Macaron
• Go-json-rest
• Beego
• Pat
• Fasthttprouter
• Lion
• Httptreemux
• Baa
• Go-restful
• Gin
• Martini
• Lars
• Bone
• Gocraft
• Gorilla
• Httprouter
• Iris
• Tango
• Vulcan
• Possum
• Denco
• Traffic
• Ace
• Fasthttp-routing
• Go-tigertonic
• Fasthttp
• R2router
• Goji
• Gojiv2
• Echo

Basic test

First, we look at some of the performance of the web framework when the business logic processing time is 0ms,10ms,100ms,500ms respectively.

The number of concurrent tests is 5000.

1	- D30s http:/127.0. 0.1:8080/hello

Average processing time (Latency)

Memory consumption

Annotations:

1. Possum in the test when there are more than n http: multiple response.WriteHeader calls errors, it performance is relatively low. The following test possum are also problematic.
2. The default Go standard library achieves high performance
3. Processing time 10ms and 100ms, the performance difference between the frameworks is not particularly large, but the 500ms throughput rate is very bad.
4. The router/web framework, based on the fasthttp implementation, behaves very well, such as Iris, Fasthttprouter, fasthttp-routing, echo-fasthttp, but Echo-fasthttp is compatible with Net/http, Performance is a little bit worse.

If you turn on HTTP pipelining, Fasthttp will be much better than the NET/HTTP implementation framework.

Concurrent Volume Testing

We tested the performance of the web framework in the case of 100,1000,5000 with a business logic processing time of 30ms.

Annotations:

1. Most of the frameworks don't have much of a poor performance.
2. Fasthttp performance is still very good, is the best performance framework, especially in the case of large concurrency
3. When concurrency is 1000, most frames have a throughput rate of 30,000/s, and most of the two-generation frames can reach 40,000/s when the concurrency is 5000.

If you turn on HTTP pipelining, Fasthttp will be much better than the NET/HTTP implementation framework.

In the test, most of the go Web framework performance can be, plus the processing time of the test after the performance difference is not very large, not as clear as the test routing function.
Fasthttp performance is very good, it is important to consider that if you choose it as a Web framework, your code will be difficult to migrate to other frameworks, because it implements the standard library Net/http interface.

2016/04/19 update : Added test data for delay time latency and memory consumption.