[Mono-dev] FastCGI Performance
Sergey Zhukov
svg at ngs.ru
Wed Apr 9 19:01:53 UTC 2014
Thank you too, etienne, for testing and commiting bug fixes.
On Tue, 2014-04-08 at 21:33 +0200, etienne.champetier at free.fr wrote:
> 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