Brian Overstreet wrote:
> Any comments on this case?
>
> Thanks,
> Brian
>
> ------------------------------------------------------------------------------
> Additional Apache2 Modules mod_python and mod_ruby
>
> 04 February 2009
>
> 1. Summary and motivation
>
> 1.1. Introduction
>
> This project delivers Apache modules mod_python and mod_ruby
> to the Apache2 (PSARC/2007/586) in OpenSolaris.
>
>
Is there a compelling use case for mod_ruby? It doesn't seem to get much
respect these days.
> Modules allow Apache to integrate and provide functionality
> during runtime that were not available during compile time.
>
> 1.1.1 mod_python
> From modpython.org[1] "mod_python is an Apache module that embeds
> the Python interpreter within the server. With mod_python you can
> write web-based applications in Python that will run many times
> faster than traditional CGI and will have access to advanced
> features such as ability to retain database connections and other
> data between hits and access to Apache internals"
>
> 1.1.2 mod_ruby
> From modruby.net[2] "mod_ruby embeds the Ruby interpreter into the
> Apache web server, allowing Ruby CGI scripts to be executed
> natively. These scripts will start up much faster than without
> mod_ruby."
>
> This project integrates the most recent stable releases of
> mod_python[1] 3.3.1 and mod_ruby[2] 1.2.6
>
>
Any idea about the recent mod_ruby 1.3.0?
> This case seeks Minor Release Binding.
>
> 2. Technical issues
>
> 2.1. Key objects
>
> 2.1.1.1 mod_python Apache objects
> /usr/apache2/2.2/libexec/mod_python.so
> /usr/apache2/2.2/libexec/${ISAINFO}/mod_python.so
> /etc/apache2/2.2/conf.d/python.conf
>
Does python.conf automatically load mod_python? It is sometimes nice
that features are auto-enabled, but because of all the stuff loaded into
Apache already, it has a huge vsize which in combination with the
default prefork MPM means that a lot of swap space is required.
(I don't have any particular solution to how to auto-enable
Apache-related features without that problem ;) )
> 2.1.2.1 mod_ruby Apache objects
>
> /usr/apache2/2.2/libexec/mod_ruby.so
> /usr/apache2/2.2/libexec/${ISAINFO}/mod_ruby.so
>
there's no 64-bit version of mod_ruby, right?
> /etc/apache2/2.2/conf.d/ruby.conf
>
same concern about ruby.conf
> 4. Packaging and Delivery
>
> The modules will be split into two parts. One the apache part which
> consists of modules loadable into apache, and another the scripting
> library part. It was chosen to split the packages into a native
> component and a library part as this is the approach taken by the upstream
> components. They allow the native part (.so file) and language library
> to be installed separately.
>
is one of these parts useful without the other?
> The apache modules will be delivered under the cluster SUNWCapch22m.
> This cluster will carry SUNWapch22m-python and SUNWapch22m-ruby.
>
in the context of all the various Apache plug-ins (PHP, mod_security,
mod_jk, etc.), why are mod_python and mod_ruby treated together in this
manner?
> The scripting library part of mod_python will be delivered under
> SUNWPython-apache.
>
Is SUNWPython the name of the Python interpreter package it uses?
(Python 2.6 IIRC)
> 6. Limitations
> 1. mod_ruby
> mod_ruby is known to be unstable under Worker MPM for apache
> (threaded MPM)
>
will ruby.conf disable it with worker MPM?
> Prefork MPM for mod_ruby is somewhat expensive as each apache process
> has to load the entire ruby runtime and the libraries.
>
> 64 bit support for mod_ruby is dependent on the parent ruby package
> delivering 64 bit libruby.so (As of now, ruby does not deliver a 64
> bit library.)
>
> 2. mod_python
> The mod_python is bulky under Prefork MPM (same as ruby).
> mod_python under Worker is stable but for most applications over it
> (e.g. Django) it is recommended to run Prefork MPM.
>
any idea why it is recommended not to use Django or other apps with
worker+mod_python?
>
