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 <[email protected]>:

> 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 <[email protected]>:
>
> Nice I will pull and check it out.
>>
>> Good work.
>>
>> Greg
>>
>>
>> On Sat, Apr 12, 2014 at 7:50 PM, Nikita Tsukanov <[email protected]>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 <[email protected]>:
>>>
>>> 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
>>>> [email protected]
>>>> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>>>>
>>>
>>>
>>> _______________________________________________
>>> Mono-devel-list mailing list
>>> [email protected]
>>> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>>>
>>>
>>
>>
>> --
>> Le doute n'est pas une condition agréable, mais la certitude est absurde.
>>
>
>
_______________________________________________
Mono-devel-list mailing list
[email protected]
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Reply via email to