-
-
Notifications
You must be signed in to change notification settings - Fork 1.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
🤗 What's the main difference in the throughout between v1.* and v2.*? #1139
Comments
Thanks for opening your first issue here! 🎉 Be sure to follow the issue template! If you need help or want to chat with us, join us on Discord https://gofiber.io/discord |
Please see v2 - Changelog |
go.mod's contents: go 1.15 require ( |
@Fenny There are no any problems for me to correctly use v2. The original go programs need many modificiations before they can successfully run, but what made me surprise is that the result throughput of v2 falls to 11600 requests/s from acround 12800 requests/s of v1 according to several stress tests. The tested url is http://server-ip:3000/api/v1/book/. What is the root cause for the above test result? What should I do to improve it or how should I understand that? The new program which can be compiled with fiber2 looks like the following:
|
Source code of book.GetBooks:
There are only 3 simple records in the local sqlite database. |
Is there anyone who would be so kind as to explain the performance differences between fiber v1.* and v2.*? |
Could you provide an easy and runnable repo to reproduce your issue? And tell us which benchmark loader you use. |
The source code of tested go application using fiber v1 and v2 can be found from the above code.
One corresponding output is: I have the both executable files of fiber application and vegeta, but it seems not a good idea to upload them and actually github does not accept such files here. |
Sorry, I don't think these code is complete and runnable. By any chance can you at least make |
And I can see |
The complete test programs that use fiber v2 are as follows:
Related configuration of
The url (http://fiber-app-ip:3000/api/v1/rtest/) is to obtain a string value from redis by calling redis's get. The result throughput is similar with that of accessing local sqlite; I guess this is because of capacity limitation of the fiber service. |
@kiyonlin All the tests are executed on CentOS Linux release 7.8.2003. The test server has 6 cpu cores and 64Gb of memory. Fiber v2 application has a different banner with that of fiber v1 application and it looks like the following:
|
I think I found the reason. This config The vegeta result on my machine looks like {"latencies":{"total":30829800748,"mean":237152,"50th":132145,"90th":159838,"95th":201268,"99th":816517,"max":32812825,"min":81229},"bytes_in":{"total":910000,"mean":7},"bytes_out":{"total":0,"mean":0},"earliest":"2021-02-05T08:42:43.680300663+08:00","latest":"2021-02-05T08:42:53.680191261+08:00","end":"2021-02-05T08:42:53.680388308+08:00","duration":9999890598,"wait":197047,"requests":130000,"rate":13000.14222415596,"throughput":12999.886062498605,"success":1,"status_codes":{"200":130000},"errors":[]} |
@kiyonlin You are right and I found the maximum throughput can reach 30880 requests/s in my environment where fiber application and Redis are located on different servers, which I think is a great test result. But there is a throughput decline about 400 requests/s when I attacked The detailed result of v1: Corresponding test result of v2: I suppose we can conclude that fiber is an outstanding web application from these results. But wheter is it fair if we say there is no noticeable performance improvement and actually there may be certain performance decline sometimes after upgrading to fiber v2? |
I think the limitation is on db(sqlite/redis), not the framework. You can test |
@kiyonlin I agree with you; but what's your opinion when comparing the test results of fiber v1 and v2? |
see #773 (v2 Benchmarks). But the most important thing is the breaking change of api. |
I still don't know what we should think about the performance degradation of fiber V2 in accessing the database. I think this is a general problem and I don't think such a problem should occur in the update of a large new version. I see that fiber V2 supports more and more functions and features, but I still don't know what the main added value is and whether it is worth it. I will be glad to see other opinions. |
Maybe it is because fiber is faster and database can hardly to catch up. |
We have not observed any performance regressions from v1 to v2. I think it would be best for you to create a new issue with a small example (preferably one route) that demonstrates the regression, and we can discuss v2 in this issue.
The main feature of v2 is the error handling. It is now more elegant and natural. Also, processing of many routes is faster, there is new middleware (monitor, rewritten session, compress improvements and more). All our middleware also uses a standardized storage interface, implemented in https://github.com/gofiber/storage. In addition, Fiber v1 is considered legacy. While we will still update it with security fixes, eventually it will be unsupported. Like any other major package update, it is better to change your code sooner than later. |
Question description
I had some stress tests on fiber v1.14.6 by accessing a local sqlite (query a few records) or remote redis (get a short string value) and found that the result throughtput can up to around 12000 requests/s.
But the above sentence actually downloads and uses fiber v1.14.6, rather than v2.*. What I wonder is how to let it use fiber v2 instead and the performance diference between the two major versions.
Code snippet Optional
The text was updated successfully, but these errors were encountered: