[Mono-dev] FastCGI Performance

Mon Apr 7 21:29:08 UTC 2014

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).

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.

Regards,
Nikita

2014-04-08 1:04 GMT+04:00 Giuliano Barberi <gbarberi at aotaonline.com>:

> 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.
>
> 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 https://github.com/txdv/LibuvSharp 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.
>
>
> On Mon, Apr 7, 2014 at 4:38 PM, Nikita Tsukanov <keks9n at gmail.com> wrote:
>
>> 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.
>>
>> 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).
>>
>> Regards,
>> Nikita
>>
>>
>> 2014-04-07 19:52 GMT+04:00 Giuliano Barberi <gbarberi at aotaonline.com>:
>>
>>> 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.
>>>
>>> Regards
>>> On Apr 7, 2014 10:20 AM, "Marcelo Zabani" <mzabani at gmail.com> wrote:
>>>
>>>> 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.
>>>> 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.
>>>> 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
>>>> http://beeder.com.br/_stats
>>>>
>>>> Don't be scared by the large response times for some of the URLs, as
>>>> those are usually contacting Facebook through Fb's API.
>>>>
>>>>
>>>> On Mon, Apr 7, 2014 at 8:02 AM, Giuliano Barberi <
>>>> gbarberi at aotaonline.com> wrote:
>>>>
>>>>> Have you benchmarked it to see how it compares to the existing FastCGI
>>>>> implementation?
>>>>>
>>>>> Regards
>>>>>
>>>>>
>>>>> On Sun, Apr 6, 2014 at 11:03 PM, Marcelo Zabani <mzabani at gmail.com>wrote:
>>>>>
>>>>>>  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:
>>>>>> https://github.com/mzabani/Fos
>>>>>> It is also available at NuGet.
>>>>>>  ------------------------------
>>>>>> From: Greg Najda <gregnajda at gmail.com>
>>>>>> Sent: 06/04/2014 22:43
>>>>>>
>>>>>> To: Giuliano Barberi <gbarberi at aotaonline.com>
>>>>>> Cc: Mono Developer List <mono-devel-list at lists.ximian.com>
>>>>>> Subject: Re: [Mono-dev] FastCGI Performance
>>>>>>
>>>>>>  Someone looked into Mono FastCGI performance a couple months ago
>>>>>> and made a series of blog posts:
>>>>>>
>>>>>>
>>>>>> http://forcedtoadmin.blogspot.com/2013/11/servicestack-performance-in-mono-p1.html
>>>>>>
>>>>>> http://forcedtoadmin.blogspot.com/2013/11/servicestack-performance-in-mono-p2.html
>>>>>>
>>>>>> http://forcedtoadmin.blogspot.com/2013/12/servicestack-performance-in-mono-p3.html
>>>>>>
>>>>>> He ended up writing a replacement for the Mono FastCGI server instead
>>>>>> of changing it because of architectural changes:
>>>>>> https://github.com/xplicit/HyperFastCgi
>>>>>>
>>>>>>
>>>>>> On Sun, Apr 6, 2014 at 7:43 PM, Giuliano Barberi <
>>>>>> gbarberi at aotaonline.com> wrote:
>>>>>>
>>>>>>> After looking at some of the Mono web benchmarks (
>>>>>>> http://www.techempower.com/benchmarks/#section=data-r8&hw=i7&test=json&s=2&p=13ydj4-0 )
>>>>>>> I got very curious as to why FastCGI performance was so much lower than
>>>>>>> when using a C# libevent implementation.
>>>>>>>
>>>>>>> If you look at nancy-libevent2 vs nancy benchmarks, the only
>>>>>>> difference is a C# wrapper around libevent (
>>>>>>> https://github.com/kekekeks/evhttp-sharp ) 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.
>>>>>>>
>>>>>>> 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 (
>>>>>>> http://www.techempower.com/benchmarks/#section=data-r8&hw=i7&test=json ).
>>>>>>> I've done a bit of analysis on where the bottleneck is and everything I've
>>>>>>> found is pointing to the FastCGI implementation.
>>>>>>>
>>>>>>> Regards
>>>>>>> --
>>>>>>> Giuliano Barberi
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> 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
>>
>>
>
>
> --
> Giuliano Barberi
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ximian.com/pipermail/mono-devel-list/attachments/20140408/ca3cf787/attachment-0001.html>