Mailing List Archive: Zope: Dev

Will ZServer help me in this scenario?

Index | Next | Previous | View Threaded

skip at mojam

Mar 6, 1999, 8:50 AM

Post #1 of 6 (428 views)
Permalink

Will ZServer help me in this scenario?

Glad to see this list has been created.

I am currently using ZopeHTTPServer in the following architecture:

Apache <-----> ZopeHTTPServer <-----> Musi-Cal DB
HTTP XML-RPC

Some requests from the net (searches) require a full round-trip to the
database. Other things, like displaying an otherwise static DTML page,
don't. The problem is that the ZopeHTTPServer is single-threaded at the
moment, so if a search takes a long time (say, a couple seconds), simple
stuff like calling a DTML template (which might execute in a tenth of a
second), block. This, of course, causes Apache to get its britches in a
twist and lots of its child processes start to pile up, memory gets short,
yadda, yadda, yadda. I've had some trouble with deadlocks when trying to
run ZHS multi-threaded (probably missed some object that needed to be
locked).

Will running ZServer with its asyncore/asynchat modules help alleviate this
problem? Will I need to make changes to Fredrik Lundh's XML-RPC code to
make this work? (XML-RPC is a given at this point. We're calling
Musi-Cal's database from both Python and Perl at this point and it works
great.) How stable is the ZServer alpha release? If it's mostly the FTP
and PCGI support that is still experimental, I can live with that since I
don't use either one.

Thanks,

Skip Montanaro | Mojam: "Uniting the World of Music" http://www.mojam.com/
skip [at] mojam | Musi-Cal: http://www.musi-cal.com/
518-372-5583

amos at aracnet

Mar 6, 1999, 12:32 PM

Post #2 of 6 (421 views)
Permalink

Re: Will ZServer help me in this scenario? [In reply to]

At 10:50 AM 3/6/99 -0500, Skip Montanaro wrote:
>
>Glad to see this list has been created.
>
>I am currently using ZopeHTTPServer in the following architecture:
>
> Apache <-----> ZopeHTTPServer <-----> Musi-Cal DB
> HTTP XML-RPC
>
>Some requests from the net (searches) require a full round-trip to the
>database. Other things, like displaying an otherwise static DTML page,
>don't. The problem is that the ZopeHTTPServer is single-threaded at the
>moment, so if a search takes a long time (say, a couple seconds), simple
>stuff like calling a DTML template (which might execute in a tenth of a
>second), block.

Actually you can run ZopeHTTPServer in multi-threaded mode. See the docs in
the doc string. Basically you just use the -t switch. It's not a very smart
threaded server, for example, it has no thread pool. But it works, assuming
you're publishing a module which is safe for concurrent access by multiple
threads.

>This, of course, causes Apache to get its britches in a
>twist and lots of its child processes start to pile up, memory gets short,
>yadda, yadda, yadda. I've had some trouble with deadlocks when trying to
>run ZHS multi-threaded (probably missed some object that needed to be
>locked).

Hmm. So you did use it in multi-threaded mode? As I am sure you know,
concurrency is not a trivial issue. Getting all the locking right can be hard.

>Will running ZServer with its asyncore/asynchat modules help alleviate this
>problem?

Yes and no. If you won't/can't make you module safe for concurrent access,
no server will be able to publish it faster than one request at a time.
However, ZServer has an interesting architecture where by input and output
are handled separately than publishing. Effectively, I/O is multi-threaded
(thanks to asyncore/asynchat), while module publishing is multi-threaded
using a thread pool (out of the box the size of the thread pool is 1). So,
even if you decide not to publish your module concurrently ZServer will
probably give you a little win over ZopeHTTPServer in single-threaded mode.

>Will I need to make changes to Fredrik Lundh's XML-RPC code to
>make this work?

I don't know much about this code, but I doubt it is causing any
concurrency issues or otherwise for you.

>(XML-RPC is a given at this point. We're calling
>Musi-Cal's database from both Python and Perl at this point and it works
>great.)

Cool!

>How stable is the ZServer alpha release?

It's OK. I personally wouldn't use it for production purposes at this time.
There are lots of changes that Jim and I have talked about that will make
it better. As soon as I get some time I'll put together another release and
then we'll be into beta territory. But this is still probably a couple
weeks out, considering all the other stuff I'm working on.

>If it's mostly the FTP
>and PCGI support that is still experimental, I can live with that since I
>don't use either one.

These are definitely rougher than HTTP, though there are still some issues
with HTTP (you might want to turn off chunking), and I'm not satisfied that
error handling and logging are all working perfectly.

Good luck.

-Amos

skip at mojam

Mar 6, 1999, 3:01 PM

Post #3 of 6 (421 views)
Permalink

Re: Will ZServer help me in this scenario? [In reply to]

Skip> Will I need to make changes to Fredrik Lundh's XML-RPC code to
Skip> make this work?

Amos> I don't know much about this code, but I doubt it is causing any
Amos> concurrency issues or otherwise for you.

I guess what I meant to say is will I need to modify the I/O that XML-RPC
does to take advantage of Medusa's multi-threading I/O? Alternatively, will
not making a change reduce or eliminate the multi-threading? Fredrik's
xmlrpclib module uses vanilla httplib to communicate with the server. Does
loading asnycore/asynchat do something to fiddle with the I/O in standard
packages or do you have to explicitly modify them to use it?

Thx,

Skip Montanaro | Mojam: "Uniting the World of Music" http://www.mojam.com/
skip [at] mojam | Musi-Cal: http://www.musi-cal.com/
518-372-5583

petrilli at amber

Mar 6, 1999, 6:15 PM

Post #4 of 6 (421 views)
Permalink

Re: Will ZServer help me in this scenario? [In reply to]

On Sat, Mar 06, 1999 at 05:01:25PM -0500, skip [at] mojam wrote:
>
> Skip> Will I need to make changes to Fredrik Lundh's XML-RPC code to
> Skip> make this work?
>
> Amos> I don't know much about this code, but I doubt it is causing any
> Amos> concurrency issues or otherwise for you.
>
> I guess what I meant to say is will I need to modify the I/O that XML-RPC
> does to take advantage of Medusa's multi-threading I/O? Alternatively, will
> not making a change reduce or eliminate the multi-threading? Fredrik's
> xmlrpclib module uses vanilla httplib to communicate with the server. Does
> loading asnycore/asynchat do something to fiddle with the I/O in standard
> packages or do you have to explicitly modify them to use it?

You might look at some of what Sam has done in the latest releases of
Medusa... it has some integration with XML-RPC in an MAJOR alpha level.
It might be a good starting point though.

Chris
--
| Christopher Petrilli ``Television is bubble-gum for
| petrilli [at] amber the mind.''-Frank Lloyd Wright

amos at aracnet

Mar 9, 1999, 11:13 AM

Post #5 of 6 (421 views)
Permalink

Re: Will ZServer help me in this scenario? [In reply to]

At 05:01 PM 3/6/99 -0500, you wrote:
>
> Skip> Will I need to make changes to Fredrik Lundh's XML-RPC code to
> Skip> make this work?
>
> Amos> I don't know much about this code, but I doubt it is causing any
> Amos> concurrency issues or otherwise for you.
>
>I guess what I meant to say is will I need to modify the I/O that XML-RPC
>does to take advantage of Medusa's multi-threading I/O?

Hmm. If you want to do your I/O using async sockets, you'll need to do a
little digging. As someone mentioned, I think there's a start at that in
the medusa distribution, or at least in CVS.

>Alternatively, will
>not making a change reduce or eliminate the multi-threading?

I'm not sure I completely understand, but let me pose this scenario.
ZServer handles I/O between the browser and your published Python module.
It uses async sockets. Your published module uses xmlrpc over vanilla
httplib to get some data from another server. Then the results are sent
back to the browser by ZServer.

This seems like the preferred solution to me. I can't think of any reason
not to do the above, and it would be much simpler than trying to figure out
how to use async sockets in your published module.

>Fredrik's
>xmlrpclib module uses vanilla httplib to communicate with the server. Does
>loading asnycore/asynchat do something to fiddle with the I/O in standard
>packages or do you have to explicitly modify them to use it?

asyncore doesn't change your sockets, it just provides a framework to
handle them for you. So you won't have a problem if you decide to do some
socket communication without the framework. In fact in your case I suspect
that everything will flow much more sanely if you ignore asyncore and do
your socketing that way you're used to.

Good luck.

-Amos

amos at aracnet

Mar 9, 1999, 10:47 PM

Post #6 of 6 (422 views)
Permalink

Re: Will ZServer help me in this scenario? [In reply to]

At 10:25 PM 3/9/99 -0500, Skip Montanaro wrote:

>Here's a slightly different question. I'm running Apache, ZopeHTTPServer
>and a backend database server. Apache (pre)forks, ZHS is multi-threaded and
>the database server is single-threaded. If a long-running query is being
>processed by the database server is the multi-threaded ZHS blocked or can
>other threads run concurrently?

If you run ZHS in multi-threaded mode it does not block. It will continue
to accept new connections. If all those connections need to wait for a
single-threaded database server, then you don't gain much by running in
multi-threaded mode.

>Even if ZHS doesn't block completely, more and more queries can pile up.

Right.

>ZHS has no capability to limit the number of simultaneous threads,

Yes, but ZServer does. You can set ZServer's thread pool size.

>and
>Apache's process limit is normally pretty high, so you can get a very bad
>failure mode. While it would appear at first that running a multi-threaded
>ZHS would be a win (allows short-running stuff that can be handled
>completely by the published module to complete), I think the bad (nay,
>catastrophic) failure mode suggests otherwise.

I'm not sure how things would work out in real life. I suggest you do some
tests to see how things perform under a heavy load.

If ZHS is creating too many threads, you might want to switch to ZServer.
If you don't like running alpha software, you might want to change ZHS to
use a thread pool, which wouldn't be very hard. (Not that I'm volunteering ;-)

Otherwise, you might want to start caching results of your database
queries, this could potentially help you quite a bit, no matter what server
mix you end up using.

Finally, I have no idea what your database server is like, but if there are
any easy ways to make it multi-threaded or simply faster, go for it ;-) It
sounds like this is where your performance bottleneck lies.

Good luck.

-Amos

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads