[Mono-dev] FastCGI, was: Silverlight early implementation thoughts.

[Marek Habersack]

On Mon, 07 May 2007 21:29:49 +0200, Robert Jordan <robertj at gmx.net> scribbled:

> Hey,
Hey Robert,

[snip]
> >> One requirement that I have is that the FastCGI bridge supports
> >> auto-configuration, or some other easy form of configuration.
> > Yep, that will be part of the implementation, although I believe it is more
> > a feature of xsp itself than a bridge.
> 
> I doubt FastCGI would be easier to configure.
I believe in quite the contrary :)

> 
> Let's have a look at a typical FastCGI configuration:
> 
> FastCgiServer /usr/lib/mono/www/mono-fastcgi-server
> <Directory /usr/lib/mono/www/>
> 	SetHandler fastcgi-script
> </Directory>
> Alias /aspnet-app-name /usr/lib/mono/www/mono-fastcgi-server
> 
> If the whole URL namespace should be consumed by mono
> (e.g. to enable ASP.NET application auto-confguration),
> the apache config gets even worse:
> 
> FastCgiServer /usr/lib/mono/www/mono-fastcgi-server
> <Directory /usr/lib/mono/www/>
> 	SetHandler fastcgi-script
> </Directory>
> Alias /mono-global-handler /usr/lib/mono/www/mono-fastcgi-server
> Action mono-handler /mono-global-handler
> SetHandler mono-handler
This is still much easier to cope with than mod_mono abrakadabra, IMHO :)
Even if some people will consider it to be harder, the configuration above is
specific to apache only and with FastCGI we will be able to use any other
webserver that supports the protocol. This is, in my eyes, the biggest
advantage of having such bridge (in addition to using a standard,
well-supported protocol to handle the requests).

> Configuring an application-to-mono-process mapping, easily
> to achieve with mod_mono, will become a nightmare with FastCGI.
> Moreover, the config snippets above must be inserted in
> every vhost, otherwise the vhosts will share the same
> mono-fastcgi-server process.
That's not entirely true. Please read

http://www.fastcgi.com/mod_fastcgi/docs/mod_fastcgi.html#FastCgiWrapper

With the help of the above you can create a dynamic setup that suits your needs.
Also, the FastCGI server process receives full information about the request,
therefore virtual server handling can be done on the mono/xsp side by
configuring just one vhost in apache to answer on any and all IP numbers we
want to service and dealing with vhost dispatch after apache hands the
connection to us.

> And since HttpResponse.TransmitFile won't be as efficient as it
> used to be under mod_mono (which simply passes the file name
> to apache), even more apache config voodoo is required (and that's
> the best case).
We don't need to go that way, I think. It must be remembered that we won't be
apache-specific anymore - so any webserver-specific hacks should be forbidden
anyway. If the performance of HttpResponse.TransmitFile is not enough, we can
improve it (I don't know if it uses sendfile(2), but if it doesn't - we should
make it use that syscall and the performance should be better than with
apache. There are also other OS-specific tricks we can use, like the new
splice (2) syscall in Linux).

best regards,

marek
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20070508/2d7d38a7/attachment.bin