Over the past couple of years, I've run Spyce under all of the
configuration methods. This is a report on my experiences in the hopes
it will be helpful to anyone else on the list (or others who read it in
the future). In particular, it is a report on how to run Spyce
similar to the way Tomcat runs JSPs. The docs set up Spyce to run like
PHP -- a very different animal from JSP.
As a veteran JSP (tomcat) programmer converted to Spyce, I struggled
with the pool and persistent objects. I created an application that
had shared object cache pool. I expected this shared pool to be
available to all pages, but to my surprise I found multiple instances
of the pool! There is no way to tell which pool you will get when a
For example, I programmed my web site with a Data Layer in between the
database and the spy pages. This was in typical MVC fashion, as is
often done in JSP. In particular, I needed to place both session and
user objects in the pool for future use. This way the user object only
has to be created once. When objects go unused for a specified amount
of time, they are removed from the cache. It is imperative that only
one cache exist. If two instances of Spyce exist in memory, two caches
will exist and two identical user objects will exist. Changes to one
user object will not be reflect in the other, and the two overwrite
Here's how each method of running Spyce does persistence:
mod_python -- Summary: mod_python runs spyce like PHP, not like JSP:
This is the "preferred" method of running Spyce according to the docs.
However, it runs several instances of the Spyce engine (both Apache and
mod_python do this). This is the preferred method of running Spyce *if
you need a PHP-like environment*. In other words, each call starts and
kills the page. No carryover between pages or even requests to the
same page can occur. Even the shared "pool" module will exist per
Spyce engine. Multiple pools will exist. So the pool is only good for
read-only objects, such as database connections. This method does not
work for JSP-like operation.
cgi -- Summary: cgi runs spyce like PHP, not like JSP:
This method runs the spyce engine from start to end for each page
called. Therefore, it is very similar to the mod_python method, with
even less persistence. The pool module is created and destroyed with
each page. Cgi is slow and inefficient anyway. This method does not
work for JSP-like operation.
fastcgi -- Summary: fastcgi runs spyce like PHP, but is able to run
The fastcgi engine runs outside of Apache, so it has the ability to run
a single persistence engine. But by default, fastcgi will instantiate
multiple Spyce engines--very similar to mod_python. To overcome this,
add "-processes 1" to the FastCgiServer line in httpd.conf. This will
force the fcgi server to instantiate only one process, and hence only
one engine. In this mode, the pool module is shared across all pages
and all requests. Global variables are instantiated only once. This
is JSP-like behavior where a spy page can retain state across calls. I
used fastcgi for two years with a fair amount of success.
Fastcgi has some quirks that I found difficult to work with. The most
important one is the fastcgi server restarts itself at random
intervals, clearing the pool, global variables, caches, and so forth.
If you are keeping session objects in a shared cache, current users on
your site will have to log back in since the session objects are
cleared. I spent many hours tracing the fcgi code to figure out why it
did this. There are some errors in either fastcgi's C code or in the
fcgi module provided with Spyce that cause this to happen. If absolute
uptime is required without restarts, I would not use fastcgi.
Web server proxy - Summary: Great for JSP-like Spyce:
The proxy mode for Spyce uses mod_rewrite to redirect spyce requests to
a separate, running Spyce server. This is very similar to the way
Tomcat runs -- tomcat runs as a separate program, and a connector in
Apache reroutes requests to Tomcat. In other words, Apache and
Tomcat/Spyce talk to one another but run separately.
The drawback to this method is you have to set your server up to run
the Spyce server as a daemon separately. In Linux, you have to create
an /etc/init.d entry so Spyce runs as a regular service on the machine.
This isn't difficult, but it's not documented. I've posted a file to
http://warp.byu.edu/spyce_daemon.py that does this exact thing.
Although Spyce can already run as a daemon, the provided file is more
linux-like (with start, stop, and restart commands).
The benefit is you have total control over the Spyce engine. If you
turn on Spyce threading (spyce.conf), it runs quite fast. One of my
sites uses SSL. Apache decodes the SSL and forwards the request as
normal. Spyce doesn't know the difference, so no SSL support is
required in Spyce. It's great.
In summary, I suggest that developers who want to run Spyce like
JSP/tomcat should use the web server proxy mode. It has proven very
robust and fast for me. Apache takes care of all regular files, and
Spyce takes care of .spy files. Is it as fast as mod_python? I
haven't done testing on the two, but it feels just as fast. I suspect
a full test would show it a little behind mod_python, but not by far.
YMMV. I think something about the PHP vs. JSP modes in Spyce should be
discussed in the docs. Developers coming to Spyce may come from PHP or
from JSP, and the two are very different when it comes to persistence.
Each will expect a certain behavior. The ability to keep persistent
objects in memory is one of the primary reasons I don't use PHP (yes, I
know about shared memory modules, but they are a mess to set up in
PHP). Spyce, OTOH can do PHP or JSP style! I'd be happy to write up
a few paragraphs about it if Rimon wants.
Comments are welcome. Correct me if I'm wrong in any of this. Cheers.
Conan C. Albrecht, Ph.D.
Brigham Young University