Thanks for the responses.
I guess I was confused by the comments in the canBeThreaded() method in
Servlet.py which says:
''' Returns 0 or 1 to indicate if the servlet can be multithreaded.
This value should not change during the lifetime of the object. The
default implementation returns 0. Note: This is not currently used. '''
I just assumed from the 'Note: This is not currently used.' part that
this method didn't work. :-)
What I'm trying to understand is how Webware (and Cheetah) works in
comparison to the Servlet API (which is where I'm migrating from)
It seems to me that changing canBeThreaded(self) to return 1 would make
Webware act like the default settings of a typical Java Servlet
container. After developing Java servlets (and related apps), the
common wisdom that using the SingleThreadModel (which stores a pool of
Servlet instances much like the default webware setup) is a BAD idea
because of performance reasons. The bottleneck being the number of
incoming requests. The default setting is 10 Servlet instances right?
So what happens if your back end processing is taking 5-10 seconds to
process (say a long-winded XML parse or database query) and you have 20
requests coming in every 2-5 seconds? It seems to me that Webware
would choke and/or your clients would give up because of all the
blocking going on.
Of course you could set Webware to keep 100 instances around but then
you're limited to "guessing" what your client request rate would be
which is almost guaranteed to be wrong in a public web site. Note
that I'm currently building a site that probably won't need more than
the default instance pool that Webware provides but I'm trying to come
up with a programming methodology for building Webware applications
that makes sense to me and will avoid me having to switch between two
very different programming models.
On Monday, December 2, 2002, at 03:01 AM, Ian Bicking wrote:
> On Mon, 2002-12-02 at 01:32, Tavis Rudd wrote:
>> If you decide to use the 'thread-shareable' approach, you'll probably
>> have to
>> spend some extra time working around issues that most webware users
>> never thought about. However, it could, theoretically, reduce the
>> footprint of your application. In some situations it might also
>> yeild small
>> performance gains.
> In practice, I think you'll see little in the way of speed or memory
> improvements. Having 10 instances of a servlet sitting around instead
> of 1 isn't a big memory loss -- or if it is, there are many ways to
> with it without making the servlets threadsafe. In particular, in
> sleep() you can delete (or set to None) attributes you've set up in
> awake() or elsewhere.
> As far as speed, I think there will be even less of an improvement.
> Essentially you'll be storing the same information in the transaction
> object instead of the servlet object -- but it should be entirely
> equivalent speed-wise, in both cases you are accessing an instance
> variable, with the same speed implications. Perhaps if you don't use
> instance variables, and the transaction is then just sent as an
> to functions, this might be a bit faster.
> There are many conveniences to coding with non-threadsafe servlets, and
> it makes factoring significantly easier. Pooling works well, and is
> Webware's alternative to threadsafeness (but only for servlets --
> everything else still has to be threadsafe or pooled on its own, as