<div dir="ltr"><div><div>You shouldn't worry much about "plain-HTTP vs. FastCGI", since
 HTTP/1.1 has that wonderful connection keep-alive feature well 
supported by nginx, and FastCGI's request multiplexing is very rarely 
supported by proxying-web servers (nginx doesn't have support for that, 
for example).<br>
</div><div><br>The main bottleneck of evhttp is the fact that it's able 
to utilize only one CPU core per listened socket (main event loop is 
single-threaded). I. e. it's impossible to accept connection on one 
evbase and pass that socket to evhttp on another. So the lack of "worker
 thread" concept for I/O limits benchmark value to 90K rps. With some 
trivial patches for libevent2 it will be possible to reach 300-350K rps 
on the same hardware. But in that case we have to ship patched version 
of libevent with the library itself.<br>
<br></div>Regards,<br></div>Nikita</div><div class="gmail_extra"><br><br><div class="gmail_quote">2014-04-08 1:04 GMT+04:00 Giuliano Barberi <span dir="ltr"><<a href="mailto:gbarberi@aotaonline.com" target="_blank">gbarberi@aotaonline.com</a>></span>:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Nikita, thanks for your work on evhttp-sharp. I have looked into the Mono source and saw that too about how Mono just has an IO threadpool to complete the requests. I wonder if the overhead it adds is very large though or if it's still possible to make it efficient enough. <div>



<br></div><div>The only thing that I don't like about the evhttp-sharp implementation is that we have to proxy the requests from the webserver to evhttp. A libuv solution would be interesting as well and could be implemented as a FastCGI wrapper instead of proxying the requests manually. There are already some wrappers around libuv for C# like <a href="https://github.com/txdv/LibuvSharp" target="_blank">https://github.com/txdv/LibuvSharp</a> so it might not be hard to do the rest. Granted the evhttp-sharp performance is already great and this would only be worth it if it improves performance at the end of the day.</div>



</div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Apr 7, 2014 at 4:38 PM, Nikita Tsukanov <span dir="ltr"><<a href="mailto:keks9n@gmail.com" target="_blank">keks9n@gmail.com</a>></span> wrote:<br>


<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div>Author of that libevent-wrapper reporting in. It seems that the implementation of asynchronous sockets in Mono is limited to the original Win32 API model with I/O completion ports, (i. e. multiple threads from a thread pool waiting for some events from sockets, done at Windows kernel level). On Linux/MacOS Mono has to emulate that by running a separate thread for epoll/kqueue event loop and then queueing callbacks passed to BeginRead/Write to a "common" thread pool. This approach will always cause some thread-communication overhead, so it's almost impossible to create an efficient socket server implementation using System.Net.Sockets.<br>



<br></div>It might be worth to create some single-threaded socket I/O stack using libuv and async/await model with custom synchronization context (actual ReadAsync and WriteAsync don't even need to return Task, just something that has GetAwaiter method).<br>



<br></div>Regards,<br></div>Nikita<br></div><div class="gmail_extra"><br><br><div class="gmail_quote">2014-04-07 19:52 GMT+04:00 Giuliano Barberi <span dir="ltr"><<a href="mailto:gbarberi@aotaonline.com" target="_blank">gbarberi@aotaonline.com</a>></span>:<br>



<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><p dir="ltr">I think just running the same test as evhttp-listener in the TechemPower Benchmark where it serializes JSON is fine. All we are looking for is a comparison. If we submit the test to them on Github then it should be available for the next benchmark too. Seems like we could add the HyperFastCgi and the FOS implementations. So far the evhttp one is super fast but it relies on native code so it has some custom code to pick either the Windows DLL or the Linux SO and needs those dependencies installed separately. It would be great to have a fast C# implementation.</p>





<p dir="ltr">Regards</p><div><div>
<div class="gmail_quote">On Apr 7, 2014 10:20 AM, "Marcelo Zabani" <<a href="mailto:mzabani@gmail.com" target="_blank">mzabani@gmail.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">






<div dir="ltr">I have not compared the fastcgi implementation per se, because it is not very easy to test only the underlying fastcgi implementations and I never had the time for that.<div>Fos, however, is a highly asynchronous server implementation, and I've seen it dealing with a lot of connections simultaneously. I haven't benchmarked it properly and compared it to other servers yet, but I'll try to do that in the next two weeks.</div>







<div>I run a website with Fos and I get 10-20ms average response time (measured as Fos -> Nginx, that is, not counting the time it takes for the response to reach the user) with static pages. In case you want to take a better look at these numbers, take a look at <a href="http://beeder.com.br/_stats" target="_blank">http://beeder.com.br/_stats</a></div>







<div><br></div><div>Don't be scared by the large response times for some of the URLs, as those are usually contacting Facebook through Fb's API.</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">







On Mon, Apr 7, 2014 at 8:02 AM, Giuliano Barberi <span dir="ltr"><<a href="mailto:gbarberi@aotaonline.com" target="_blank">gbarberi@aotaonline.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">







<div dir="ltr">Have you benchmarked it to see how it compares to the existing FastCGI implementation?<div><br></div><div>Regards</div></div><div class="gmail_extra"><br><br><div class="gmail_quote"><div>On Sun, Apr 6, 2014 at 11:03 PM, Marcelo Zabani <span dir="ltr"><<a href="mailto:mzabani@gmail.com" target="_blank">mzabani@gmail.com</a>></span> wrote:<br>









</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div><div>
<div>
<div style="FONT-SIZE:11pt;FONT-FAMILY:Calibri,sans-serif">In case you want to host an OWIN application with Mono and FastCgi, you may wanna take a look at a project of mine, Fos: <a href="https://github.com/mzabani/Fos" target="_blank">https://github.com/mzabani/Fos</a><br>










It is also available at NuGet.</div></div>
</div><div dir="ltr">
<hr>
<span style="FONT-SIZE:11pt;FONT-FAMILY:Calibri,sans-serif;FONT-WEIGHT:bold">From: </span><span style="FONT-SIZE:11pt;FONT-FAMILY:Calibri,sans-serif"><a href="mailto:gregnajda@gmail.com" target="_blank">Greg Najda</a></span><br>









<span style="FONT-SIZE:11pt;FONT-FAMILY:Calibri,sans-serif;FONT-WEIGHT:bold">Sent: </span><span style="FONT-SIZE:11pt;FONT-FAMILY:Calibri,sans-serif">06/04/2014 22:43</span><div><br>
<span style="FONT-SIZE:11pt;FONT-FAMILY:Calibri,sans-serif;FONT-WEIGHT:bold">To: </span><span style="FONT-SIZE:11pt;FONT-FAMILY:Calibri,sans-serif"><a href="mailto:gbarberi@aotaonline.com" target="_blank">Giuliano Barberi</a></span><br>









<span style="FONT-SIZE:11pt;FONT-FAMILY:Calibri,sans-serif;FONT-WEIGHT:bold">Cc: </span><span style="FONT-SIZE:11pt;FONT-FAMILY:Calibri,sans-serif"><a href="mailto:mono-devel-list@lists.ximian.com" target="_blank">Mono Developer List</a></span><br>










<span style="FONT-SIZE:11pt;FONT-FAMILY:Calibri,sans-serif;FONT-WEIGHT:bold">Subject: </span><span style="FONT-SIZE:11pt;FONT-FAMILY:Calibri,sans-serif">Re: [Mono-dev] FastCGI Performance</span><br><br></div></div></div>







<div>
<div dir="ltr"><div>Someone looked into Mono FastCGI performance a couple months ago and made a series of blog posts:<br><br><a href="http://forcedtoadmin.blogspot.com/2013/11/servicestack-performance-in-mono-p1.html" target="_blank">http://forcedtoadmin.blogspot.com/2013/11/servicestack-performance-in-mono-p1.html</a><br>












<a href="http://forcedtoadmin.blogspot.com/2013/11/servicestack-performance-in-mono-p2.html" target="_blank">http://forcedtoadmin.blogspot.com/2013/11/servicestack-performance-in-mono-p2.html</a><br><a href="http://forcedtoadmin.blogspot.com/2013/12/servicestack-performance-in-mono-p3.html" target="_blank">http://forcedtoadmin.blogspot.com/2013/12/servicestack-performance-in-mono-p3.html</a><br>












<br></div>He ended up writing a replacement for the Mono FastCGI server instead of changing it because of architectural changes: <a href="https://github.com/xplicit/HyperFastCgi" target="_blank">https://github.com/xplicit/HyperFastCgi</a></div>











<div class="gmail_extra"><br><br><div class="gmail_quote">On Sun, Apr 6, 2014 at 7:43 PM, Giuliano Barberi <span dir="ltr"><<a href="mailto:gbarberi@aotaonline.com" target="_blank">gbarberi@aotaonline.com</a>></span> wrote:<br>











<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div style="font-family:arial,sans-serif;font-size:13px">After looking at some of the Mono web benchmarks ( <a href="http://www.techempower.com/benchmarks/#section=data-r8&hw=i7&test=json&s=2&p=13ydj4-0" target="_blank">http://www.techempower.com/benchmarks/#section=data-r8&hw=i7&test=json&s=2&p=13ydj4-0</a> ) I got very curious as to why FastCGI performance was so much lower than when using a C# libevent implementation.</div>













<div style="font-family:arial,sans-serif;font-size:13px"><br></div><div style="font-family:arial,sans-serif;font-size:13px">If you look at nancy-libevent2 vs nancy benchmarks, the only difference is a C# wrapper around libevent ( <a href="https://github.com/kekekeks/evhttp-sharp" target="_blank">https://github.com/kekekeks/evhttp-sharp</a> ) vs Mono FastCGI. Since Mono uses epoll underneath which is what libevent uses afaik, I would not expect there to be such a gap in performance. </div>













<div style="font-family:arial,sans-serif;font-size:13px"><br></div><div style="font-family:arial,sans-serif;font-size:13px">I'm curious whether performance of FastCGI is being looked at or if this is expected. Mono when using FastCGI benchmarks almost at the bottom of the list when compared to many other technologies ( <a href="http://www.techempower.com/benchmarks/#section=data-r8&hw=i7&test=json" target="_blank">http://www.techempower.com/benchmarks/#section=data-r8&hw=i7&test=json</a> ). I've done a bit of analysis on where the bottleneck is and everything I've found is pointing to the FastCGI implementation.</div>













<div style="font-family:arial,sans-serif;font-size:13px"><br></div><div style="font-family:arial,sans-serif;font-size:13px">Regards</div><span><font color="#888888"><span><font color="#888888"><span><font color="#888888">-- <br>


Giuliano Barberi
</font></span></font></span></font></span></div><span><font color="#888888"><span><font color="#888888">
<br>_______________________________________________<br>
Mono-devel-list mailing list<br>
<a href="mailto:Mono-devel-list@lists.ximian.com" target="_blank">Mono-devel-list@lists.ximian.com</a><br>
<a href="http://lists.ximian.com/mailman/listinfo/mono-devel-list" target="_blank">http://lists.ximian.com/mailman/listinfo/mono-devel-list</a><br>
<br></font></span></font></span></blockquote></div><span><font color="#888888"><br></font></span></div><span><font color="#888888">
</font></span></div></blockquote></div><span><font color="#888888"><span><font color="#888888"><br><br clear="all"><div><br></div>-- <br>Giuliano Barberi
</font></span></font></span></div><span><font color="#888888">
</font></span></blockquote></div><span><font color="#888888"><br></font></span></div><span><font color="#888888">
</font></span></blockquote></div><span><font color="#888888">
</font></span></div></div></div><span><font color="#888888">
<br>_______________________________________________<br>
Mono-devel-list mailing list<br>
<a href="mailto:Mono-devel-list@lists.ximian.com" target="_blank">Mono-devel-list@lists.ximian.com</a><br>
<a href="http://lists.ximian.com/mailman/listinfo/mono-devel-list" target="_blank">http://lists.ximian.com/mailman/listinfo/mono-devel-list</a><br>
<br></font></span></blockquote></div><br></div>
<br>_______________________________________________<br>
Mono-devel-list mailing list<br>
<a href="mailto:Mono-devel-list@lists.ximian.com" target="_blank">Mono-devel-list@lists.ximian.com</a><br>
<a href="http://lists.ximian.com/mailman/listinfo/mono-devel-list" target="_blank">http://lists.ximian.com/mailman/listinfo/mono-devel-list</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br>Giuliano Barberi
</div>
</div></div></blockquote></div><br></div>