[Mono-dev] FastCGI Performance

[Giuliano Barberi]

I'm gonna close this issue. I mainly opened it to ask about whether that
would help a lot but I can see from you said it won't since you're already
pooling. The evhttp-sharp implementation does use native calls though it
uses evhttp from libevent but the author says the main bottleneck at this
point is that its single threaded in case you want something to compare
against.

Regards


On Tue, Apr 8, 2014 at 12:03 PM, xplicit <svg at ngs.ru> wrote:

> 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.
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>



-- 
Giuliano Barberi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ximian.com/pipermail/mono-devel-list/attachments/20140408/b2b88ef6/attachment.html>