The fastest router only needs 1.8% of the time http.ServeMux needs. The logs below show, that http.ServeMux has only medium performance, compared to more feature-rich routers. The third number is the amount of heap memory allocated in bytes, the last one the average number of allocations made per repetition. The second column shows the time in nanoseconds that a single repetition takes. If you are unfamiliar with the go test -bench tool, the first number is the number of repetitions the go test tool made, to get a test running long enough for measurements. In the StaticAll benchmark each of 157 URLs is called once per repetition (op, operation). The only intention of this benchmark is to allow a comparison with the default router of Go's net/http package, http.ServeMux, which is limited to static routes and does not support parameters in the route pattern. It might not be a realistic URL-structure. It is just a collection of random static paths inspired by the structure of the Go directory. The Static benchmark is not really a clone of a real-world API. But it gives us a first hint how efficient or wasteful a router works. As long as the router doesn't require Megabytes of memory, it should be no deal breaker. Moreover main memory is cheap and usually not a scarce resource. The routing structure of Pat is simple - probably too simple. Now, before everyone starts reading the documentation of Pat, this low memory consumption comes at the price of relatively bad routing performance. The first place goes to Pat, followed by HttpRouter and Goji. I'm pretty sure you can detect a pattern 😉 Router The best 3 values for each test are bold. The following table shows the memory required only for loading the routing structure for the respective API. Ubuntu 14.04 amd64 (Linux Kernel 3.13.0-29), fresh installationīesides the micro-benchmarks, there are 3 sets of benchmarks where we play around with clones of some real-world APIs, and one benchmark with static routes only, to allow a comparison with http.ServeMux.Intel Core i5-2500K (4x 3,30GHz + Turbo Boost), CPU-governor: performance.So keep in mind, that I am not completely unbiased 😌 Results In fact, this benchmark suite started as part of the packages tests, but was then extended to a generic benchmark suite. Personally, I prefer slim and optimized software, which is why I implemented HttpRouter, which is also tested here. If you care about performance, this benchmark can maybe help you find the right router, which scales with your application. The frameworks are configured to do as little additional work as possible. But since we are only interested in decent request routing, I think this is not entirely unfair. This benchmark tries to measure their overhead.īeware that we are comparing apples to oranges here, we compare feature-rich frameworks to packages with simple routing functionality only. Lately more and more bloated frameworks pop up, outdoing one another in the number of features. Moreover, many of them are very wasteful with memory allocations, which can become a problem in a language with Garbage Collection like Go, since every (heap) allocation results in more work for the Garbage Collector.
Unfortunately, most of the (early) routers use pretty bad routing algorithms. Since the default request multiplexer of Go's net/http package is very simple and limited, an accordingly high number of HTTP request routers exist. Go is a great language for web applications. Of course the tested routers can be used for any kind of HTTP request → handler function routing, not only (REST) APIs. Some of the APIs are slightly adapted, since they can not be implemented 1:1 in some of the routers. This benchmark suite aims to compare the performance of HTTP request routers for Go by implementing the routing structure of some real world APIs.
0 kommentar(er)
