[Zope] FW: zope sybase database adapter..

[Chris McDonough]

This is moved to the Zope list from private email.

Brian Takashi Hooper wrote:
> 
> Hi Chris, thanks for the quick answer!
> 
> On Thu, 03 Feb 2000 21:54:19 -0500
> Chris McDonough <chrism@digicool.com> wrote:
> (BTW, go home, it's late :-) )
>  
> [snip]
> 
> > So as far as overrunning your available Sybase connections, I don't
> > think you have to sweat it much as long as you have at 
> least 7 available
> > licensed connections and you've only got one connection to 
> the database
> > within Zope.  I'm not really quite sure why you're only seeing four
> > threads active in a -t 20 environment, however.  It may 
> have something
> > to do with the timing of the requests as they come in to Zope via
> > ZServer (Zope may only need four threads to serve back the data even
> > though you say your client runs with six).  There's a lot 
> of stuff going
> > on in there.  :-)
> I'll say - well I certainly didn't know anything about the magic 7
> number limit (after I knew what to search for, I did find the magic
> limit in ZODB/DB.py), that's very interesting.
> 
> I am still wondering about my application threads, tho.  I have been
> loading my server using a threaded client with gradually increasing
> numbers of threads... basically what I've been doing is increasing the
> number of virtual clients until my request latency goes significantly
> up, and vmstat on the server end indicates things are pretty 
> busy.  Then
> I started looking at thread.get_ident() in
> ZServer/PubCore/ZServerPublisher, something like:
> 
> import creosote, thread
> 
> class ZServerPublisher:
>     def __init__(self, accept):
>        while 1:
>            try:
>                name, request, response=accept()
>                creosote.spew('REQUEST handled by: %d' % 
> thread.get_ident())
>                ^^^^^^^^^^^^^
>                publish_module(
>                    name,
>                    request=request,
>                    response=response)
>            finally:
>                response._finish()
>                request=response=None
> 
> I don't know if this way of looking at things makes sense or not,
> obviously Heisenberg's principle applies...
> 
> Anyway I (of course) get something like this if I listen to UDP on 
> 7739:
> 
> REQUEST handled by: 3076
> REQUEST handled by: 2051
> REQUEST handled by: 3076
> REQUEST handled by: 2051
> REQUEST handled by: 2051
> REQUEST handled by: 2051
> REQUEST handled by: 2051
> REQUEST handled by: 2051
> REQUEST handled by: 3076
> REQUEST handled by: 2051
> REQUEST handled by: 2051
> REQUEST handled by: 2051
> REQUEST handled by: 3076
> REQUEST handled by: 2051
> REQUEST handled by: 3076
> REQUEST handled by: 2051
> REQUEST handled by: 2051
> 
> Looking at things via vmstat, small requests seem to be CPU 
> bound; large
> requests seem to be I/O bound; I guess this makes sense...
> 
> However, no matter what I try (requesting large (>50K) 
> documents, small
> documents (<1K), etc.) I can't seem to visualize more than 3 
> threads at
> once.  Am I looking at this in totally the wrong way? 
> Assuming 7 is the
> magic pool limit, then it seems like I would want to try to get things
> up to 7 simultaneous RDB connections if I'm serving out all RDB-using
> pages.  
> 
> Any ideas?
> 
> --Brian
> 
> P.S.  Should we move this discussion to the Zope list?  Maybe someone
> else out there is wondering the same thing, or better yet 
> already knows
> the answer?
>