Any time I see a chart about web server performance without displaying the corresponding error rate and latency numbers I start to think that the author does not understand the performance aspect of HTTP services entirely.
The performance comes from using <a href="https://github.com/valyala/fasthttp" rel="nofollow">https://github.com/valyala/fasthttp</a> instead of the stdlib net/http. From this project's FAQ:<p><i>>Why creating yet another http package instead of optimizing net/http?<p>Because net/http API limits many optimization opportunities.</i>
The graph on the homepage says echo2-fasthttp processed almost half the requests that iris processed, but in half the time. Wouldn't that make them approximately equal? I <i>think</i> what it's trying to communicate is the number of requests each framework managed in 500ms, but it isn't clear.
That graph is really confusing, is the x axis a progression of processing times from 0 up to ~1000ms? If so then wouldn't it mean that Echo-2-fasthttp has nearly as good requests/second?
Features: <a href="https://kataras.gitbooks.io/iris/content/features.html" rel="nofollow">https://kataras.gitbooks.io/iris/content/features.html</a><p>(seems to be missing a data/SQL/ORM layer)<p>Usage docs for rest api: <a href="https://kataras.gitbooks.io/iris/content/render_rest.html#usage" rel="nofollow">https://kataras.gitbooks.io/iris/content/render_rest.html#us...</a>
Could someone clarify: why is Go faster than say Python? And if the answer is just that it's a lower level language and therefore has less overhead, why not just use C?
Discussed on reddit before and I found that Iris uses caches to speed up.<p><a href="https://www.reddit.com/r/golang/comments/4a8yit/is_this_the_fastest_go_web_framework/" rel="nofollow">https://www.reddit.com/r/golang/comments/4a8yit/is_this_the_...</a>
There was a discussion about Iris on the github issue tracker of Gin, another framework, dated March 13 2016:<p><pre><code> https://github.com/gin-gonic/gin/issues/560
</code></pre>
Some benchmark were made too.
Not only is this page riddled with typos that lead me to doubt the quality of the code, the concept of a framework is fundamentally complex and at odds with the goals of Go.