Zope-Dev February 2004

zope-dev@zope.dev

73 participants
73 discussions

HELP NEEDED!!!
by Rajesh s shiggaon 12 Feb '04

12 Feb '04

Hi everyone, I am getting an error Error Type: OperationalError Error Value: (1205, 'Lock wait timeout exceeded; Try restarting transaction') i am trying to insert vaules into 2 tables (MYSQL). In the first table i make a new record and get the unique id for tht using THE MYSQL FUNCTION . but when it try to insert a record for the next table for which i am using this id....it gives an error. but when i try to give a static id for the second table....it is not giving any error. so i guess it is bcoz of transactions of zope... how to overcome this problem...any sugesstions are welcome!!!!! Regards, Rajesh Rajesh Shiggaon

1 0

Persistence Module Confustion (fwd)
by D. Bickle 12 Feb '04

12 Feb '04

I am trying to import the MailHost module that has dependencies with the Persistence package. The interpreter complains that it cannot load the Persistence modules and when I examine the package there is no content or modules. How can I fix my code to resolve these dependencies? Have the Persistence modules been deprecated? Thanks,

2 1

Adapters in Zope 2
by Santi Camps 12 Feb '04

12 Feb '04

Hi all, I know that adaptors are introduced in zope3 but, anybody knows if this technique can be used in zope2 ? I've been trying to add some extra functionallity to a Folder object without inheriting, but I'm not able to make it work. To maintain the adapted object publishable I've rewrited __getattr__, but then some extra problems appears. Anybody knows if there is a way to use adapters in zope2 ? Or, if not, there is some other way to add functionallity on-the-fly, without inheriting ? Thanks in advance -- Santi Camps http://zetadb.sourceforge.net

6 9

Re: [Zope-dev] Re: How to make Zope fail nicely under high load?
by Peter Sabaini 12 Feb '04

12 Feb '04

Bjorn Stabell wrote: > Hi Peter, > > >>I think I did find some sort of knob for this >> >>For Apache 2.0, mod_cache, dir. CacheIgnoreCacheControl could be used >>for this >>http://httpd.apache.org/docs-2.0/mod/mod_cache.html >> >>For Apache 1.3 mod_proxy, dir. CacheMaxExpire could do >>http://httpd.apache.org/docs/mod/mod_proxy.html#cachemaxexpire > > > I think this will force Apache to cache content no matter if the > content's headers have cache control settings, but will it force Apache > to not re-request the content if the browser forces a reload? > (Ctrl-refresh in IE.) This really should be tested, but as far as I can remember it did serve from cache rather than rerequest. Its been some time since I did this (and at another company) and unfortunately I cant remember this too clearly... From the 'CacheIgnoreCacheControl' at least it does sound like it would ignore the spec and serve cached content though. cheers, peter.

1 0

RE: [Zope-dev] How to make Zope fail nicely under high load?
by Bjorn Stabell 12 Feb '04

12 Feb '04

Jan-Wijbrand wrote: [...] > You are able to store *and* share data over ZEO Clients in a > TemporaryStorage by making the ZSS serve this > TemporaryStorage to its ZCs. You could mount this storage as > temp_folder I guess, but any other mount point would work too. Coooool.... :) > Not sure, but I'd expect so, whether this has significant > perfomance advantages over a 'normal' ZODB served by the ZSS. Probably, and it's no-packing as well. Very nice. We'll definitely use this then. Bye, -- Bjorn

1 0

RE: [Zope-dev] How to make Zope fail nicely under high load?
by Bjorn Stabell 12 Feb '04

12 Feb '04

Jamie writes: > Lennart Regebro wrote: > > OK, you get the problem that images may not load even if > the main page > > does, but is that really worse for the end user than not getting > > anything? > > As I've been saying, if you do that, they will reload > repeatedly making the problem worse. If the images are fluf, > and the user knows they are fluf, then *maybe* they won't > reload, and your pages will simply appear ugly. But then you > have to ask yourself, why am I sending fluf images that > degrades the overall user experience of my application? > Clearly there's more optimization that could be done to your > application. If you run Apache as a caching reverse proxy (caching surrogate server) then images will be served from Apache. Only the dynamic HTML pages are served from Zope, so having them fail without regards to sessions is relatively okay. Images and other static content are almost guaranteed to load correctly, and if they didn't, a straight reload from the client will not reload cached images. Regards, -- Bjorn

3 3

RE: [Zope-dev] How to make Zope fail nicely under high load?
by Bjorn Stabell 12 Feb '04

12 Feb '04

> Bjorn wrote: > > I wonder if Zope also processes requests that have been closed from > > the client end? I know Zope will continue processing a request even > > if it times out at least (so you can do long-running requests, like > > packing, through the web). Many (all?) of these 300 requests would > > have been closed by the time Zope got to process them, and so Zope > > shouldn't bother with them. Casey wrote: > Why would they be closed by the client? Two scenarios: 1) The user gets tired of waiting for the page to come up after a few seconds and stopes or reloads it. This is very common if the response time is above a few seconds. 2) After clicking on a link the user discovers another, better link, and quickly clicks on that one as well. This is quite common for me, at least :) When Zope gets very loaded, response times suffer and these things happen more often; in our case with 300 requests in the pending queue, nobody would bother waiting 10 minutes for their page to come up (they'd stop the page loading and go somewhere else), so all the requests (most likely) would be needless; Zope is in fact just processing dead requests. Bye, -- Bjorn

2 1

Zope, forking and cpu-affinity
by Dario Lopez-Kästen 12 Feb '04

12 Feb '04

Hello, I hope this is not the wrong list... I have some trouble doing cpu-afiinity wiht zope. I can affinitise the parent process just fine, however, zope forks and the children get spread out all over the CPUs. I do not yet wish to resort to shell-hacking the ouput of ps -ef, so I was wodering if there are some documents that explain the forking nature of zope. Any help is appreciated. Sincerely, /dario -- -- ------------------------------------------------------------------- Dario Lopez-Kästen, IT Systems & Services Chalmers University of Tech.

3 4

RE: [Zope-dev] How to make Zope fail nicely under high load?
by Bjorn Stabell 12 Feb '04

12 Feb '04

Richard Jones wrote: > On Thursday 12 February 2004 01:23, Casey Duncan wrote: > > What kinds of requests are these? Do they all require a dynamic > > output? If not, then you should put better caching in front of Zope, > > or at a minimum tweak you caching headers so that some > > could be served as 304s for instance. > > > > If they are all dynamic, how dynamic? How different is the page for > > one session than another? If much of the page is the same then you > > might benefit from an ESI approach where you cache parts of > > pages and assemble them in the cache, serving only small pieces from Zope. > > > > I'm a bit surprised that you have not (from what I can > > see), used the most common Zope speedup (and often the cheapest overall): Buy more > > hardware and use ZEO. > > I was going to suggest these things too. And a bunch of other > stuff. A while ago, I wrote a page about making Zope go faster - it might help. > > http://zope.org/Members/richard/docs/zope_optimisation.html Okay, I'd better explain our situation in more detail, then. Richard, Casey, thanks. Except for using ZEO, we're already doing everything Richard and you mentions. Zope only serves pages (no images etc) that are dynamic, the object cache is set at 20,000 objects with only 2 threads (otherwise we got too much deactivation of objects), and we also use the RAM Cache Manager for static bits of dynamic pages. We could probably have used it more, but since it can't cache persistent objects, it's a bit of a pain sometimes. The point is, our template is very dynamic, and our application (a BBS) is very dynamic as well. We have done one round of optimization (basically making things as cacheable as possible) and after testing the scalability now we're going to do another round of optimization, tweaking the algorithm and removing as many ZCatalog searches as possible. One of the optimization we're thinking of is storing results of ZCatalog searches (e.g., number of replies to postings) in volatile variables so we don't have to run the catalog search at all. We'd like to use memory space shared between threads for this. Using ZEO would require us to store this in the ZODB. I'm sure we can make the application run faster, but we'd like to support 500-1000 simultaneous users whereas now we can only support 20-25! I don't know if we can scale it enough just by tweaking the application. Another option is to scrap Zope for the BBS part and use one of the fully featured, and optimized, BBS applications for PHP. That would definitely be a safer choice, but would require extra application integration time (user database, searching). Regards, -- Bjorn

3 2

RE: [Zope-dev] How to make Zope fail nicely under high load?
by Bjorn Stabell 11 Feb '04

11 Feb '04

Toby wrote: [...] > Zope's ZServer manages a queue of requests that have been > recieved over http, > but not dispatched to the publisher. This is handled in > PubCore/ZRendezvous.py. I suspect this queue will be holding > your backlog. > > You might get some benefit from capping the length of that queue. Thanks Toby. It doesn't seem like that queue (the requests list) has a cap at all. Have been stresstesting Zope for a few minutes and the queue is up to 300+ requests in the backlog queue. Not sure how to force a 503 return from within ZRendezvous.handle(), though; that's ZServer medusa magic. 300 requests at 1 request per 2 seconds yields a backlog of work of 10 minutes. This is before we've started optimizing. I wonder if Zope also processes requests that have been closed from the client end? I know Zope will continue processing a request even if it times out at least (so you can do long-running requests, like packing, through the web). Many (all?) of these 300 requests would have been closed by the time Zope got to process them, and so Zope shouldn't bother with them. Bye, -- Bjorn

3 2

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

Zope-Dev February 2004