[Mono-dev] FastCGI Performance

Mon Apr 7 22:06:24 UTC 2014

libuv itself doesn't have its own HTTP-server implementation, but if you
want to create a general-purpose network I/O stack it's better to use
libuv, since it's capable of using I/O completion ports on Windows
(libevent uses select() which is good only for debugging). AFAIK, libuv was
initially created for such stack of nodejs.

Regards,
Nikita

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

> Is that why you mention libuv? Does it not have the same issue as libevent
> in that regard?
>
>
> On Mon, Apr 7, 2014 at 5:29 PM, Nikita Tsukanov <keks9n at gmail.com> wrote:
>
>> 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
>>>
>>
>>
>> _______________________________________________
>> 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/dba655b1/attachment-0001.html>