Python web development, really

[Jacob Smullyan]

Ian Bicking <ianb at colorstudy.com> writes:

> This data can be used for caching.  IMHO the convenience of this caching
> makes increasing performance easier in Webware than, say, SkunkWeb
> (which uses multiple processes, and so makes data sharing harder). 
> SkunkWeb claims the multiple processes mean that it can better utilize
> multi-processor systems because it is not pinned by the global
> interpreter lock.  This is true, but there are many ways to increase
> performance, and I believe easy data sharing and caching is more of a
> benefit than multiple processors would be.  But anyway, I digress...

I'm a developer for SkunkWeb, and would make a different value
judgement, although I have no factual disagreement with Mr. Bicking.
I would agree that SkunkWeb's multiple-process design does not
necesarrily translate into a performance advantage in all scenarios,
and the published SkunkWeb propaganda may make too much of this design
decision (although I think it was an important factor for the
applications for which it was initially designed).  There is a cost to
be paid in the heaviness of the application (which doesn't matter
much) and the relative difficulty in doing some kinds of resource
sharing that would be simpler or perhaps more efficient in a
multi-threaded context.

There are some pluses to a multi-process design beyond transcending
the limitations of the global interpreter lock.  You never ever have
to worry about thread sychronization in writing for SkunkWeb, which
will make some developers' lives easier.  You don't have to worry
about crashing the whole application server.  It just fits with
SkunkWeb's rather open, un-boxed-in aesthetic; it is an easy design to
live with, for some folks.  Let's just say, without starting a
religious war about threads (I'm agnostic!) that a multi-process
alternative is nice to have.

As for caching, SkunkWeb is I believe very strong in this area, as it
does have a very useful component cache, which stores component output
on disk; and this cache can be controlled with considerable finesse,
and furthermore with ease.  While access to a disk cache is not going
to be as fast as access to memory, just as with the GIL lock issue,
there are other ways of improving performance.  The convenience and
controllability of the SkunkWeb cache is a huge advantage, as it can
be utilized to the fullest with virtually no development effort.

(Incidentally, if anyone feels strongly that SkunkWeb should be able
to run in multi-threaded mode, feel free to submit patches :).  The
main challenge would be to make the Configuration object in
multi-thread mode return thread-specific information, and of course to
provide an alternate bootloader.)

Cheers,

Jacob Smullyan