[Mono-dev] FastCGI Performance

[xplicit]

>From my point of view the bollteneck currently is not in the socket library,
but in the System.Web implementation. For example, when I did benchmarks for
HyperFastCgi server, I've got such results:
Get static file from nginx - 10K rps
Get hardcoded html-response from HyperFastCgi server (without passing http
request to mono web.server) - ~5K rps. 
Yes, it's double-time drop in performance, but I think that's mostly because
static file is cached inside nginx, while using fastcgi requires additional
layer of communication throught sockets.

Then when I added mono web server to the nginx-fastcgi chain performance
dropped to 1.5-2K rps depending on the requests were served. I'm pretty
sure, if you remove all sockets references from web server and will emulate
HTTP requests directly to System.Web you won't get incredible improvement of
performance, it will still be slow. However, I might be wrong, all
performance assumptions must be measured, because sometimes you'll get
results is not what you expect.

But what I saw:
System.Web uses very slow implementation of System.Configuration. For every
request path not in cache it tries to find web.config and read some basic
stuff (globalization, authentication, etc).  Simple making globalization
<https://github.com/xplicit/mono/commit/081596b827cfcd8f8eed212c58f8869d600ac3e6>  
to be read only once now gives me 20-30% performance boost. (NB: I don't
know what's changed with mono or my system, but when I did this several
month ago, it was only about 5% addition in performance). That's why
HttpListener will be faster it does not need to handle all of these
settings.

Some terrible using of sessions cache in System.Web. I wrote a little about
issues with caching here 
http://forcedtoadmin.blogspot.ru/2013/12/unexpected-unloading-of-mono-web.html
<http://forcedtoadmin.blogspot.ru/2013/12/unexpected-unloading-of-mono-web.html> 
. When mono web tries to reload itself and recompile ASP.NET the pages it
again drops the performance.

Some performance issues due to no-caching http handlers.
Using of slow hashcodes for headers dictionary after security patch.

And so on. Every thing of these produce a little drop which become an
avalanche and wash away good performance from the web.

Finally. To be sure, what is most slow part, it should be created few
benchmarks.
1. Sockets benchmarks. Pure multi-threaded application, which returns some
test data. One application must be written on c#, other must be native.
Difference in measurement will show is C# socket implementation slow or not. 
2. System.Web benchmarks. Create two apps: one is a simulator of web
requests to System.Web, other - pure application, which also simulates
requests to some pretty simple HTTP responder.     



--
View this message in context: http://mono.1490590.n4.nabble.com/FastCGI-Performance-tp4662454p4662480.html
Sent from the Mono - Dev mailing list archive at Nabble.com.