[Mono-dev] Architectural decisions behind mod_mono
imaudi at comcast.net
Sat Mar 7 04:05:56 EST 2009
Hi all - I'm investigating the possibility of porting a site from
.NET/Windows Server to Apache/Mono and am doing some homework about running
Mono applications on the web. As it stands, it seems the two choices are
XSP, which is designed to be a test/debug server and not for highly scalable
production applications, or mod_mono which is a module that is compiled into
Apache. From what I understand, mod_mono requires mod_mono_server which
answers inbound requests over a TCP/IP socket. I'm having a hard time
understanding this design. First off, for every inbound socket opened in
Apache, a new socket is opened for mod_mono_server, along with all the
overhead on the network stack. In the Windows world, IIS hosts the CLR in
process and the two are very tightly integrated. What's stopping Mono from
incorporating this design?
I'm assuming Java does not have a separate Java server which Apache forwards
Can't Apache just be configured to natively run Mono applications in
process? Would this be a massive architectural change to the Mono runtime?
As it stands right now, I don't see a possibility for any MySpace/Facebook
level web applications running on Mono because I simply can't see mod_mono
being able to scale to that level.
Perhaps some of the hard core Mono runtime guys can comment, I'm sure
they're 843x smarter than I am and there's very good reasons why mod_mono
was designed the way it is, but I'm wondering how this compares with PHP,
Java, etc which all seem to be tightly integrated in with Apache. Are there
any plans to incorporate the Mono runtime directly into Apache, or maybe
write a highly performant Mono server similar to Sun's Java Web Server? I'm
not trying to criticize any design decisions, I'm very new to Mono and UNIX
server architecture and am just trying to understand the reasons behind
View this message in context: http://www.nabble.com/Architectural-decisions-behind-mod_mono-tp22385591p22385591.html
Sent from the Mono - Dev mailing list archive at Nabble.com.
More information about the Mono-devel-list