[Mono-dev] FastCGI Performance

[Sergey Zhukov]

To be more exact I did not write some special code for connection
pooling, but I did thread pooling for MonoWorkerRequest and tried to
pool CGI records, which are used for communication between nginx and
FastCgi server. The last one did not show any increasing in performance
for me, and I did not merge the code to master branch. The second one
can be enabled or disabled with /usethreadpool=yes|no option.

About connection pooling: KeepAlive mode reuses opened connections very
good, so for 100000 tests requests I get only 50-60 instances of
NetworkConnector are created. You can check it by adding the line

            if (cn % 10 == 0)
                Logger.Write (LogLevel.All, "cn={0}", cn);  

to the end of NetworkConnector constructor. If you see that cn is
growing, that something wrong with configuration and this produces huge
drop of performance.

Also, I'll look into benchmarks you point out and will see, what can be
done more to increase performance.


On Tue, 2014-04-08 at 13:19 -0400, Giuliano Barberi wrote:
> 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