4 ms·

> if you have light needs, or can easily restart the service on a regular basis, you may find it usable. But I'd definitely avoid deploying an MVC 3 app Can yo

by sker 15y ago

> if you have light needs, or can easily restart the service on a regular basis, you may find it usable. But I'd definitely avoid deploying an MVC 3 app Can you further elaborate on that one? Because that's exactly what I would like to do.

gecko 15y ago
Mono had two issues we hit in production for server processes: 1. The GC was poor. There's actually a couple of pieces to this one: it's non-compacting, so your app gradually slows down; and (because it's Boehm) it has to guess at what's a pointer, and sadly just doesn't do a good job, so you gradually leak RAM through no fault of your own. The new GC, which I think is called SGen, is a precise collector, so I assume that it fixes the memory leaks, but it's still non-compacting, meaning you're probably going to want to restart the process every once and awhile to prevent serious heap fragmentation. 2. Mono gradually became unstable the longer it ran. This grew exponentially worse as you added threads. Both of these issues can be circumvented by having multiple processes in a load-balanced configuration and simply restarting them every once and awhile. Heck, IIS does that with App Pool recycling anyway, and it doesn't have these issues. The FogBugz team still uses Mono to host FogBugz on Unix systems, I believe by going the reboot-every-so-often route, so I assume they've found ways of living with the above two constraints.
- jstedfast 15y ago
  Remember that Mono is open source and we'd LOVE to get patches to improve it. Bug reports also help! In the meantime, we're working hard to constantly be improving Mono, but the best way to improve free/open source software is to get involved.
- sker 15y ago
  How long ago did you experience those issues? I still have some time to go until I launch whatever it is I decide to build. I hope the Mono team finds a solution for them eventually.

by sker 15y ago

gecko 15y ago

Mono had two issues we hit in production for server processes: 1. The GC was poor. There's actually a couple of pieces to this one: it's non-compacting, so your app gradually slows down; and (because it's Boehm) it has to guess at what's a pointer, and sadly just doesn't do a good job, so you gradually leak RAM through no fault of your own. The new GC, which I think is called SGen, is a precise collector, so I assume that it fixes the memory leaks, but it's still non-compacting, meaning you're probably going to want to restart the process every once and awhile to prevent serious heap fragmentation. 2. Mono gradually became unstable the longer it ran. This grew exponentially worse as you added threads. Both of these issues can be circumvented by having multiple processes in a load-balanced configuration and simply restarting them every once and awhile. Heck, IIS does that with App Pool recycling anyway, and it doesn't have these issues. The FogBugz team still uses Mono to host FogBugz on Unix systems, I believe by going the reboot-every-so-often route, so I assume they've found ways of living with the above two constraints.

jstedfast 15y ago
Remember that Mono is open source and we'd LOVE to get patches to improve it. Bug reports also help! In the meantime, we're working hard to constantly be improving Mono, but the best way to improve free/open source software is to get involved.
sker 15y ago
How long ago did you experience those issues? I still have some time to go until I launch whatever it is I decide to build. I hope the Mono team finds a solution for them eventually.