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 <[email protected]>: > 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 <[email protected]>: > > 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, <[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 >>> >> >> >> _______________________________________________ >> 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
