[Mono-dev] FastCGI Performance
Nikita Tsukanov
keks9n at gmail.com
Wed Apr 9 00:27:20 UTC 2014
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/643250c3/attachment.html>
More information about the Mono-devel-list
mailing list