[Mono-dev] Fundamental performance problems with Mono
TThompson at Nucsafe.com
Thu Jan 7 13:02:58 EST 2010
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:
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.
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
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
entirely I/O work - copying buffers from one socket to another. Now,
doesn't implement the newer
XXXAsync Socket API that was introduced in .NET 2.0 SP1 (or more
accurately, implements it
perfunctorily ). So I was left to use the APM Socket API which produces
of garbage objects under heavy load.
When testing the server on Linux under load we saw very frequent CPU
that crippled the throughput of the server. After profiling with the
built-in profiler I confirmed that the reason for the high CPU usage was
GC collections that got more and more frequent and took more and more
I then read a little bit and realized that the Mono GC is
which might explain the long GC cycles (if it was generational it could
collected the garbage objects that were created during async socket
operations in generation 0 and probably stop there, but it has to
the entire managed heap).
So the combination of the non-generational GC and the unimplemented
Socket API result in very poor performance of the Mono server. The
throughput of the server with Mono on Linux is about half of that on
I attached the GC stats and profiling results of a 15 minute run.
Can you help me out here?
View this message in context:
Sent from the Mono - Dev mailing list archive at Nabble.com.
Mono-devel-list mailing list
Mono-devel-list at lists.ximian.com
More information about the Mono-devel-list