[Mono-dev] Fundamental performance problems with Mono

[Thad Thompson]

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