[Mono-dev] FastCGI Performance

Mon Apr 7 21:04:44 UTC 2014

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/20140407/24e2898f/attachment.html>