Re: [Mono-dev] Is mono ready for backend deployment?
On Thu, Mar 26, 2015 at 9:41 PM, Edward Ned Harvey (mono) edward.harvey.m...@clevertrove.com wrote: From: mono-devel-list-boun...@lists.ximian.com [mailto:mono-devel-list- boun...@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 tcpsocket, 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
Re: [Mono-dev] Is mono ready for backend deployment?
As an aside I was perf and stability testing some code last night and mono used less memory and was faster than the equivalent clr tests. Good job everyone :) On Thursday, March 26, 2015, Gelin Yan dynami...@gmail.com wrote: Hi All 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. I noticed several crash reports during the tests and some of them were related to mono's gc threadpool, so finally I gave up. Now We are in 2015 and mono has improved quite a bit. I want to know whether it is ready for backend? I founded many successful cases with mono but most of them are about mobile development. Could you share some experience on server side? Thanks. Regards gelin yan -- Studying for the Turing test ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Is mono ready for backend deployment?
From: Gelin Yan [mailto:dynami...@gmail.com] Unfortunately, at the time, mono crashed each time after a few seconds of pressing tests. (IAsyncResult was slightly better, it lasted a bit longer). Check the mono compatibility guide. All the async stuff, except for ASP.Net, has stabilized and is well supported, since ... I'm not sure when ... But I know it wasn't stable in 2.10 when you tested it, and it is stable now. I also know if you had checked the compatibility guide in the days of 2.10, it would indicate async was not yet stable. Familiarization with the compatibility guide and the class status guide is an important part of cross-platform development for .Net and mono. http://www.mono-project.com/docs/about-mono/compatibility/ and http://www.mono-project.com/docs/about-mono/class-status/ 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. I have not had any reason to tweak the GC, but if you post questions here about it (start a new thread) other people here are experts on GC and can answer your questions. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Is mono ready for backend deployment?
Hi Gelin, See http://opensimulator.org . We have been using mono to power a server for shared 3d virtual spaces (virtual worlds) since the project started around 2007. We do use a third party http server and threading utilities. The application uses several server stacks that perform separate functions that communicate with each other, with one providing the main interface to the user-client. -James On Thu, 2015-03-26 at 18:01 +0800, Gelin Yan wrote: Hi All 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. I noticed several crash reports during the tests and some of them were related to mono's gc threadpool, so finally I gave up. Now We are in 2015 and mono has improved quite a bit. I want to know whether it is ready for backend? I founded many successful cases with mono but most of them are about mobile development. Could you share some experience on server side? Thanks. Regards gelin yan ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Is mono ready for backend deployment?
Hi Gelin, I think mono is doing a good job, especially for backend uses. LISTEQ uses it to host their BoXedVDI Cloud Desktop software (www.listeq.com) - where the mono/.net application handles all the network I/O, video compression and encryption. I also use mono for much of the globaltuners.com infrastructure, including audio streaming, DSP and HTTPS proxying. Both systems can easily run for weeks, probably much longer if it weren't for software updates, without crashing. We were recently affected by a possible (regression) bug in mono which caused crashes while running external processes under some circumstances, but this seems to have improved. You may have to be careful with updates, but overall it works well and can run reliably for a long time. -- Ivo Gelin Yan schreef op 26-3-2015 om 11:01: Hi All 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. I noticed several crash reports during the tests and some of them were related to mono's gc threadpool, so finally I gave up. Now We are in 2015 and mono has improved quite a bit. I want to know whether it is ready for backend? I founded many successful cases with mono but most of them are about mobile development. Could you share some experience on server side? Thanks. Regards gelin yan ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Is mono ready for backend deployment?
On Thu, Mar 26, 2015 at 8:29 PM, Ivo Smits i...@ufo-net.nl wrote: Hi Gelin, I think mono is doing a good job, especially for backend uses. LISTEQ uses it to host their BoXedVDI Cloud Desktop software (www.listeq.com) - where the mono/.net application handles all the network I/O, video compression and encryption. I also use mono for much of the globaltuners.com infrastructure, including audio streaming, DSP and HTTPS proxying. Both systems can easily run for weeks, probably much longer if it weren't for software updates, without crashing. We were recently affected by a possible (regression) bug in mono which caused crashes while running external processes under some circumstances, but this seems to have improved. You may have to be careful with updates, but overall it works well and can run reliably for a long time. -- Ivo Hi Ivo Thanks. Do you have a pr for for these recent crashes? I am interested in having a look if possible. Regards gelin yan ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Is mono ready for backend deployment?
From: mono-devel-list-boun...@lists.ximian.com [mailto:mono-devel-list- boun...@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. ;-) ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
