Thank you too, etienne, for testing and commiting bug fixes.
On Tue, 2014-04-08 at 21:33 +0200, [email protected] 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" <[email protected]> > > À: "Giuliano Barberi" <[email protected]> > > Cc: "Mono Developer List" <[email protected]> > > 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 <[email protected]> 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 > > > [email protected] > > > http://lists.ximian.com/mailman/listinfo/mono-devel-list > > > > > > > > > > > > > > > -- > > > Giuliano Barberi > > > > > > _______________________________________________ > > Mono-devel-list mailing list > > [email protected] > > http://lists.ximian.com/mailman/listinfo/mono-devel-list > > _______________________________________________ Mono-devel-list mailing list [email protected] http://lists.ximian.com/mailman/listinfo/mono-devel-list
