[Mono-dev] FastCGI Performance

Nikita Tsukanov keks9n at gmail.com
Sat Apr 12 19:04:35 UTC 2014


Oh, sorry for misinformation. FrameworkBenchmarks already has experimental
and buggy implementation of the same thing (see multiworker branch). So the
good news that it can be now considered stable.


Profiling with some optimizations gave me about 20% performance boost
however.

Before:
Running 25s test @ http://127.0.0.1:8083/
  10 threads and 600 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency     6.38ms    5.51ms  59.43ms   79.82%
    Req/Sec    10.80k     3.90k   29.20k    66.14%
  2469415 requests in 24.99s, 329.70MB read
Requests/sec:  98803.25
Transfer/sec:     13.19MB


After:
Running 25s test @ http://127.0.0.1:8083/
  10 threads and 600 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency     8.06ms   12.65ms  81.59ms   90.45%
    Req/Sec    12.36k     4.94k   26.73k    71.89%
  2983443 requests in 24.99s, 398.33MB read
Requests/sec: 119391.93
Transfer/sec:     15.94MB

Regards,
Nikita


2014-04-12 21:11 GMT+04:00 Nikita Tsukanov <keks9n at gmail.com>:

> Oh, sorry for misinformation. FrameworkBenchmarks already has experimental
> and buggy implementation of the same thing (see multiworker branch). So the
> good news that it can be now considered stable.
>
> Regards,
> Nikita Tsukanov
>
>
> 2014-04-12 20:53 GMT+04:00 Greg Young <gregoryyoung1 at gmail.com>:
>
> Nice I will pull and check it out.
>>
>> Good work.
>>
>> Greg
>>
>>
>> On Sat, Apr 12, 2014 at 7:50 PM, Nikita Tsukanov <keks9n at gmail.com>wrote:
>>
>>> Hello there. Today I spent some time messing up with libevent and
>>> managed to implement multiworker mode (multiple threads accepting
>>> connections from the same socket) in my evhttp-sharp wrapper. That gave me
>>> 2.5 times faster results in benchmark (from 32K to 79K rps). Now I'll send
>>> pull request to FrameworkBenchmarks guys.
>>>
>>> Regards,
>>> Nikita Tsukanov
>>>
>>>
>>> 2014-04-09 23:51 GMT+04:00 xplicit <svg at ngs.ru>:
>>>
>>> I like this. If it provides the ability to easy change one listener to
>>>> other
>>>> and also ability to change HTTP servers it'll be awesome. By the way it
>>>> also
>>>> should provide the ability to run current ASP.NET server otherwise
>>>> people
>>>> could not migrate their web application to Linux platform. ASP.NETrequires
>>>> some additional things to startup, like create AppDomain with
>>>> appropriate
>>>> security evidence for every web application, route requests to correct
>>>> AppDomain according to virtual path and so on. These produce additional
>>>> level of complexity, which possible does not required by raw HTTP
>>>> servers,
>>>> but I think it can be simplified.
>>>>
>>>> If you guys are intrested in this, I can share some ideas and tell about
>>>> issues and constraints I met when I tried to integrate ASP.NET with
>>>> nginx.
>>>>
>>>>
>>>>
>>>> --
>>>> View this message in context:
>>>> http://mono.1490590.n4.nabble.com/FastCGI-Performance-tp4662454p4662500.html
>>>> Sent from the Mono - Dev mailing list archive at Nabble.com.
>>>> _______________________________________________
>>>> 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
>>>
>>>
>>
>>
>> --
>> Le doute n'est pas une condition agréable, mais la certitude est absurde.
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ximian.com/pipermail/mono-devel-list/attachments/20140412/84eb56b4/attachment.html>


More information about the Mono-devel-list mailing list