[Mono-dev] Fundamental performance problems with Mono

[zvikag]

Did you see this improvement using Mono or .NET on Windows? in your blog post
you talk about GC generations that don't exist in Mono GC and OOM exceptions
that I don't get.

I am also doubtful that the use of pooled buffers can alleviate the problems
in Mono since the main problem are the tons of garbage objects that are
created during BeginXXX\EndXXX calls, not the pinning of send and receive
buffers.



Thad wrote:
> 
> I feel your pain. I pulled a library across that did something similar,
> and the large GC times had a visible, stop-the-world impact on latency.
> Switching from garbage collected to managed buffers made a world of
> difference. For more on this see:
> 
> http://msdn.microsoft.com/en-us/library/system.servicemodel.channels.buf
> fermanager.aspx
> http://codebetter.com/blogs/gregyoung/archive/2007/06/18/async-sockets-a
> nd-buffer-management.aspx
> 
> After switching to managed buffers (and replicating some logic similar
> to the Async socket methods), I've had a pass-through data bridge
> running for days without a hiccup and with low CPU/memory utilization,
> even on a fairly underpowered processor. 
> 
> If you do decide to go with managed buffers you'll need to implement
> your own (or find a good library) as the WCF BufferManager in Mono won't
> really do what you want.
> 
> Regards,
> -Thad
> 
> -----Original Message-----
> From: mono-devel-list-bounces at lists.ximian.com
> [mailto:mono-devel-list-bounces at lists.ximian.com] On Behalf Of zvikag
> Sent: Thursday, January 07, 2010 10:38 AM
> To: mono-devel-list at lists.ximian.com
> Subject: [Mono-dev] Fundamental performance problems with Mono
> 
> 
> Hello all,
> The bottom line of this message is that I don't see how can one write a
> high-performance socket server in Mono...
> Here is the story:
> I am writing a proxy server using .NET Socket API. This proxy does
> almost
> entirely I/O work - copying buffers from one socket to another. Now,
> Mono
> doesn't implement the newer 
> http://msdn.microsoft.com/en-us/library/system.net.sockets.socketasyncev
> entargs.aspx
> XXXAsync Socket API  that was introduced in .NET 2.0 SP1 (or more
> accurately, implements it 
> http://www.mail-archive.com/mono-list@lists.ximian.com/msg28621.html
> perfunctorily ). So I was left to use the APM Socket API which produces
> tons
> of garbage objects under heavy load.
> When testing the server on Linux under load we saw very frequent CPU
> bursts
> that crippled the throughput of the server. After profiling with the
> mono
> built-in profiler I confirmed that the reason for the high CPU usage was
> the
> GC collections that got more and more frequent and took more and more
> time.
> I then read a little bit and realized that the Mono GC is
> non-generational
> which might explain the long GC cycles (if it was generational it could
> have
> collected the garbage objects that were created during async socket
> operations in generation 0 and probably stop there, but it has to
> traverse
> the entire managed heap).
> So the combination of the non-generational GC and the unimplemented
> XXXAsync
> Socket API result in very poor performance of the Mono server. The
> maximum
> throughput of the server with Mono on Linux is about half of that on
> Windows
> using .NET.
> 
> I attached the GC stats and profiling results of a 15 minute run.
> http://old.nabble.com/file/p27026906/profile_alloc.log profile_alloc.log
> 
> http://old.nabble.com/file/p27026906/gc_stats.log gc_stats.log 
> Can you help me out here?
> -- 
> View this message in context:
> http://old.nabble.com/Fundamental-performance-problems-with-Mono-tp27026
> 906p27026906.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
> 
> 

-- 
View this message in context: http://old.nabble.com/Fundamental-performance-problems-with-Mono-tp27026906p27075167.html
Sent from the Mono - Dev mailing list archive at Nabble.com.