[Mono-dev] FastCGI Performance
Sergey Zhukov
svg at ngs.ru
Wed Apr 9 19:20:02 UTC 2014
Marcello,
I'll try to find a way to remove ASP.NET dependency, in this case you'll
be able to reuse communication part of the HyperFastCgi and provide an
additional way to write FastCgi http servers.
On Tue, 2014-04-08 at 18:01 -0300, Marcelo Zabani wrote:
> xplicit, perhaps we could concentrate the effort of the FastCgi parts
> in HyperFastCgi in a separate library? I think both our projects and
> the community could benefit from this. I'm not sure how developed the
> FastCgi parts in HyperFastCgi are, but perhaps we could merge the good
> of both into FastCgiNet? (http://github.com/mzabani/FastCgiNet).
> At this point FastCgiNet is reasonably well documented (its code as
> well) - the best docs I've seen in any FastCgi library for .NET - so
> it shouldn't be *too* hard for other people to help.
>
>
> On Tue, Apr 8, 2014 at 4:33 PM, <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
> >
> _______________________________________________
> 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