[Mono-dev] FastCGI Performance
Nikita Tsukanov
keks9n at gmail.com
Wed Apr 9 00:37:26 UTC 2014
It's also worth not to invent that IHttpServer mechanism from scratch, but
just use existing OWIN standard ( http://owin.org/ ).
Regards,
Nikita
2014-04-09 4:27 GMT+04:00 Nikita Tsukanov <keks9n at gmail.com>:
> It would be great to create some transport-independent ASP.NET host that
> can be easily integrated with any "raw" HTTP server. I tried to dig in the
> code of default Mono implementation several months ago, but quickly gave up.
> That host should ask the user for IHttpServer implementation with
> IHttpServer defined like this:
>
> interface IHttpServer
> {
> event Action<IHttpRequest> OnRequest;
> }
>
> interface IHttpRequest
> {
> string Method {get;}
> string PathAndQuery {get;}
> //blablabla
> void Respond (int code, byte[] payload, IDictionary<string, string>
> headers);
> }
>
>
>
>
> 2014-04-09 1:01 GMT+04:00 Marcelo Zabani <mzabani at gmail.com>:
>
> 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
>>>
>>
>>
>> _______________________________________________
>> Mono-devel-list mailing list
>> Mono-devel-list at lists.ximian.com
>> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ximian.com/pipermail/mono-devel-list/attachments/20140409/fff88572/attachment-0001.html>
More information about the Mono-devel-list
mailing list