[Mono-dev] FastCGI Performance
etienne.champetier at free.fr
etienne.champetier at free.fr
Tue Apr 8 19:33:04 UTC 2014
Hi
This thread is named "FastCGI performance", but much more important than
performance is stablility, ie don't explode (10Gb memory usage :)).
I want to thanks Sergey for his HyperFastCGI, because it seems to handle
load just fine (ab -c200)(response time goes up, thread number stay at ~35,
and memory is between 90Mb and 200Mb)
----- Mail original -----
> De: "Sergey Zhukov" <svg at ngs.ru>
> À: "Giuliano Barberi" <gbarberi at aotaonline.com>
> Cc: "Mono Developer List" <mono-devel-list at lists.ximian.com>
> Envoyé: Mardi 8 Avril 2014 20:50:23
> Objet: Re: [Mono-dev] FastCGI Performance
>
> 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
>
>
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>
More information about the Mono-devel-list
mailing list