You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Thanks to TechEmpower for providing the community with so many language/framework performance test results, which bring great reference value to everyone.
Some frameworks are just 4th-layer frameworks(for TCP/UDP/UnixSocket...), which implement simple HTTP "\r\n" judgment to perform a request parsing, and then write back the HTTP response buffer. They do not have the basic conditions for being a production environment HTTP service, but they participated in this test and got a high/top performance results.
Many users in the community do not really read the test code of these frameworks, so they do not know the truth, which causes a lot of miscommunication, making users mistakenly believe that some frameworks or even languages can achieve unrealistic performance.
As a performance testing project with great influence, it should be fair and just, so I suggest removing these frameworks with incomplete functions.
If you want to test the 4th-layer performance of these not full-feature HTTP frameworks, you should open a separate test item/combination instead of comparing the 4th-layer framework(with fake HTTP implementation) with the HTTP framework.
The text was updated successfully, but these errors were encountered:
Thanks to TechEmpower for providing the community with so many language/framework performance test results, which bring great reference value to everyone.
Some frameworks are just 4th-layer frameworks(for TCP/UDP/UnixSocket...), which implement simple HTTP "\r\n" judgment to perform a request parsing, and then write back the HTTP response buffer. They do not have the basic conditions for being a production environment HTTP service, but they participated in this test and got a high/top performance results.
Many users in the community do not really read the test code of these frameworks, so they do not know the truth, which causes a lot of miscommunication, making users mistakenly believe that some frameworks or even languages can achieve unrealistic performance.
As a performance testing project with great influence, it should be fair and just, so I suggest removing these frameworks with incomplete functions.
If you want to test the 4th-layer performance of these not full-feature HTTP frameworks, you should open a separate test item/combination instead of comparing the 4th-layer framework(with fake HTTP implementation) with the HTTP framework.
The text was updated successfully, but these errors were encountered: