[Mono-dev] Is mono ready for backend deployment?

[Gelin Yan]

On Thu, Mar 26, 2015 at 9:41 PM, Edward Ned Harvey (mono) <
edward.harvey.mono at clevertrove.com> wrote:

> > From: mono-devel-list-bounces at lists.ximian.com [mailto:mono-devel-list-
> > bounces at lists.ximian.com] On Behalf Of Gelin Yan
> >
> >    A few years ago, I tried to port one of our server from .net to mono.
> At the
> > time. Mono 2.8 was just out. My server use socket (tcp almost) & thread
> > pools heavily.
>
> You're making a blanket statement, "ready."   My blanket response is:
> Yes.  Mono is ready.*
>
> * Going into a little more detail, no matter what, you must acknowledge
> that there are major architectural differences between Windows, BSD, Linux,
> etc.  Mono and .Net are enormous, and there *are* differences, and there
> always will be.  So you can never say "It's ready" meaning 100% compatible
> and bug-free.  (Guess what, in my experience, I've found about equal
> numbers of MS bugs and Mono bugs.)  What you can do instead, is to develop
> and test on multiple platforms, and anyplace where something is different,
> solve the problem.
>
> I personally develop a commercial product, that has windows/mac/linux
> client and server components, doing a lot of SSL communications over
> unreliable network connections.  We develop code on .Net, test on mono, and
> for the non-GUI server backend stuff, around 99% of the code simply works
> without any modifications.  We run into occasional snags, like, managing
> the SSL certs differently on each platform, and privilege escalation to
> bind port 443, and stuff like that, which are intrinsically different on
> different platforms.  FileSystemWatcher works perfectly on windows & linux,
> but the BSD implementation of kevent/kqueue is fundamentally flawed and
> will never work, so FSWatcher simply doesn't work (reliably) on macs.  We
> had to get Xam.Mac and use FSEvents.  Also, mutexes and inter-process
> signalling, and file locking - we've had to do work in order to support
> multi-platforms, due to fundamental differences in the different
> platforms.  It's impossible for mono (or anything not running on windows)
> to implement file locking as designed in the MS API.  Differences of
> filesystem charset, path separator character, etc.  Dramatic difference in
> RSA key generation, and absent support for EC keys...  To name a few of the
> areas that are different between .Net and mono.
>
> You might be like I was originally - assuming .Net was better - but I have
> found in many regards, neither .Net nor Mono is better.  They each are
> better in specific ways, and the number and severity of differences doesn't
> add up to a clear "one is better."  For example, I found that .Net's
> implementation of RSA key generation greatly outperforms mono's
> implementation, but mono does a lazy key generation which means 99% of the
> time you can completely skip key generation (depending on your usage
> model).  And there's a huge list like that.  Dramatic performance
> differences in SHA and stuff.
>
> We make heavy use of tcp sockets and threadpool, as well as manually
> managed threads.  Threadpool:  No issues whatsoever.  Tcp:  the timeout
> setting doesn't work unless you set it at the right time ... I forget ...
> after the connection is established?  I forget, but I could look it up.  We
> decided to manually manage the tcp timeouts.  (Not difficult; every time we
> create a TcpClient, create a timer, and when we receive bytes, consider
> resetting the timer).  Whatever you do, frigging *don't* call Dispose on a
> SslStream.  On heavily used linux servers, we had to increase the number of
> tcp sockets in kernel - I could look up details if needed -
>
> So I would say ultimately, Tcp:  Barely any issues, which were easily
> managed.  Unfortunately, SslStream was (and still is) not easily managed,
> if you happen to want a mono SslStream server.  But you didn't say SSL; you
> said TCP sockets.  ;-)
>

Hi Edward

    Thanks for sharing your experience. I am not saying .net is better. It
can't be due to .net and mono are different things. A possible reason that
people comparing these two frameworks is .net was there first.

   About bugs related to tcp&socket, I remembered there were two types of
async styles:

1. use IAsyncResult
&
2.  SocketAsyncEventArgs (MS favors this style & claims it outperforms the
first one).

Unfortunately, at the time, mono crashed each time after a few seconds of
pressing tests. (IAsyncResult was slightly better,
it lasted a bit longer).

   I had no idea what happened and I ever posted a mail in the mail list,
sure without any response.

   I guessed mono users might be more interested in use it for other
purposes instead of backend.

Another problem is related to the gc. I have some codes crashed on mono due
to OOM and I found out mono couldn't handle
that until I call System.GC.Collect() manually. The same, sgen was just out
and failed on the tests.

   Due to I haven't seen any problem on .Net (It doesn't mean .net is bug
free), so I considered mono runtime was not that stable for a heavy load
environment. That's why I finally decided not to use it in production. I
still keep an eye on mono due to I like C# and Linux too. I don't use BSD
Like system, so thank for sharing about how mono works and what's problem
on BSD Like OS.

   By the way, Do you have any info about tuning GC on mono?  When I
searched "mono, gc tuning" on google,  only a few results came out and a
little bit outdated.

Regards

gelin yan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ximian.com/pipermail/mono-devel-list/attachments/20150327/a9500c72/attachment.html>