[Mono-dev] FastCGI Performance

Marcelo Zabani mzabani at gmail.com
Mon Apr 21 16:49:13 UTC 2014


Just to add some info on *Fos*, I've just tried the Hello World json
serialization benchmark (taken from
http://www.techempower.com/benchmarks/#section=data-r8&hw=i7&test=json&s=2&p=13ydj4-0)
and in my machine I'm getting a little more than 3000 requests per second
using ServiceStack's Json Serializer. I'm not using any OWIN compatible
stacks such as Nancy, I'm just writing the response through a simple
middleware.
The good news is that after profiling it is easy to see some methods with
rather dumb implementations in Fos and FastCgiNet (the kind of code you put
a *TODO* close to) that are taking up a lot of unnecessary time. I'll see
if I can rewrite those methods over the next week to make this faster.

Has anyone else benchmarked Fos and/or FastCgiNet?


On Sat, Apr 12, 2014 at 4:04 PM, Nikita Tsukanov <keks9n at gmail.com> wrote:

> 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.
>>>
>>
>>
>
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ximian.com/pipermail/mono-devel-list/attachments/20140421/20ec89b5/attachment.html>


More information about the Mono-devel-list mailing list