[Mono-dev] FastCGI Performance

Mon Apr 7 22:20:31 UTC 2014

So mono has a single thread calling epoll then it sticks the work in the
its own threadpool implementation. How is that different than what you're
suggesting with libevent/libuv and having worker threads? Is there
something slow about mono's threadpool implementation or is there some
overhead somewhere else I am not thinking about?

Regards

On Mon, Apr 7, 2014 at 6:06 PM, Nikita Tsukanov <keks9n at gmail.com> wrote:

> 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/LibuvSharpso 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
>>
>
>
> _______________________________________________
> 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/6afd3d53/attachment-0001.html>