Improve ASP.NET performance by up to 13% #314
Conversation
On Ubuntu Server, the hard limit is 4096, which is less than the soft limit of 8192 that we're trying to use. Thus, to really use a soft limit of 8192, we need to also boost the hard limit to 8192.
Tests expect to be able to start their own desired http server on Apache's configured port.
… net.core.somaxconn=5000 When running tests that accessed MySQL, I was getting errors like: BENCHMARKING Query ... [MySQL] 2013/05/23 00:57:04 packets.go:31: EOF 2013/05/23 00:57:04 Error scanning world row: driver: bad connection exit status 1 Debugging this showed that the web server box had more connections to MySQL than expected (i.e. netstat on the MySQL box showed 100 TCP connections, but the web server box showed 1200). So there was some sort of TCP problem, perhaps lost ACKs as described in http://www.evanjones.ca/tcp-stuck-connection-mystery.html . Looking at the MySQL documentation for back_log (http://dev.mysql.com/doc/refman/5.0/en/server-system-variables.html#sysvar_back_log), it suggests that the OS setting needs to be greater than or equal to back_log. Thus, we need to set net.core.somaxconn as big as our back_log value. I tried this and the connection problems went away.
Sometimes the ActivePerl HTTP server returns a 404 for a URL that should work, so retry it until it works, but up to a max number of retries. And delay a little in between.
…Benchmarks Conflicts: installer.py
Match the overall policy of the other framework benchmarks. On my setup, this improves the requests/sec of a test like 'json' by 3-5%.
This removes: X-AspNetMvc-Version: 4.0 X-AspNet-Version: 4.0.30319 X-Powered-By: ASP.NET I didn't see any performance improvement, but this is probably a good idea in case the extra bytes cause another network packet to be needed, compared to other frameworks.
We don't need to access URLs like this because we use MVC and URL routing. On my setup, this improves the performance of the 'json' test by 13%.
|
For the record, I also disabled IIS HTTP logging in another pull request. I don't think removing other response headers is necessary, especially since it doesn't improve performance in any way and the goal of these framework benchmarks is to be realistic. But that is just my opinion.
|
|
Thanks for the updates @MalcolmEvershed and @pdonald. Glad to hear about the 13% performance bump from a small configuration change! For response headers, we specify a minimum set [1], but additional headers that are conventionally enabled by the platform or framework should be retained to be realistic as @pdonald points out. Our findings to-date have been that response headers only play a detectable role in performance when our gigabit Ethernet becomes saturated. |
|
Thanks guys. I reverted the HTTP header commit and the HTTP logging commit. |
On my setup, this improved the performance of the 'json' test by 13%:
Disable IIS HTTP logging to match the other tests. (3-5%)Remove unnecessary HTTP response headers to match the other tests. (0%, but should probably be done anyway)FYI: @pdonald, @micahasmith, @ollyw, @rafaelsc
P.S. This branch also includes some other fixes from my parent master branch. I didn't intend to include those changes with these performance improvements, but I couldn't find a way to back them out. In the future, to avoid this problem, I will keep my master branch clean and only put changes in branches off of my master branch (I think that makes sense).