Re: [Zope-dev] How to make Zope fail nicely under high load?
On Thursday 12 February 2004 00:57, you wrote: 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. Storing that in ZODB would be a bad idea. Theres no reason to think that this cache would be faster than ZCatalog. I dont see why you would be *required* to store in ZODB... just dont share your cache between publisher threads on different Zope instances. (my apologies if this is obvious) -- Toby Dickenson ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope, forking and cpu-affinity
Dieter Maurer wrote: Zope itself does not fork (unless you use system, popen or things like that; in these cases, you do not want to bind the children to the same processor). Well, I had that impression as well, but here is the output of ps on my machines (edited for cruft-removal): UID PID PPID C STIME TIME CMD zope 32538 14379 0 Feb09 00:02:32 python2.1 z2.py -X -w zope 32539 32538 0 Feb09 00:00:00 python2.1 z2.py -X -w zope 32541 32539 0 Feb09 00:00:09 python2.1 z2.py -X -w zope 32542 32539 0 Feb09 00:00:11 python2.1 z2.py -X -w zope 32543 32539 0 Feb09 00:01:52 python2.1 z2.py -X -w zope 32544 32539 0 Feb09 00:01:41 python2.1 z2.py -X -w that is more than 2 processes for a single instance... This is on both RH7.3 and RH AS 2.1... I don't think these are threads, but I couldn't say for sure (and they have different pids). I don't know how tor turn threading off for ps/top. How can I tell if these are threads or real processes? Thanks, /dario -- -- --- Dario Lopez-Kästen, IT Systems Services Chalmers University of Tech. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope, forking and cpu-affinity
On Thursday 12 February 2004 08:26, Dario Lopez-Kästen wrote: Dieter Maurer wrote: Zope itself does not fork (unless you use system, popen or things like that; in these cases, you do not want to bind the children to the same processor). Well, I had that impression as well, but here is the output of ps on my machines (edited for cruft-removal): UID PID PPID C STIME TIME CMD zope 32538 14379 0 Feb09 00:02:32 python2.1 z2.py -X -w zope 32539 32538 0 Feb09 00:00:00 python2.1 z2.py -X -w zope 32541 32539 0 Feb09 00:00:09 python2.1 z2.py -X -w zope 32542 32539 0 Feb09 00:00:11 python2.1 z2.py -X -w zope 32543 32539 0 Feb09 00:01:52 python2.1 z2.py -X -w zope 32544 32539 0 Feb09 00:01:41 python2.1 z2.py -X -w that is more than 2 processes for a single instance... one of them is the supervisor process that restarts the main zope process if it crashes. the others are all threads of one process. one main medusa thread, and 4 publisher threads. -- Toby Dickenson ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope, forking and cpu-affinity
Toby Dickenson wrote: On Thursday 12 February 2004 08:26, Dario Lopez-Kästen wrote: that is more than 2 processes for a single instance... one of them is the supervisor process that restarts the main zope process if it crashes. the others are all threads of one process. one main medusa thread, and 4 publisher threads. ah. I see - thanks. Doing some further testing on another machine tells me that on RH AS Enterprise 3 (or what's-it's-name), zope is listed as only two threads, as expected. Thank you for the clarification. Sincerely, /dario -- -- --- Dario Lopez-Kästen, IT Systems Services Chalmers University of Tech. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] How to make Zope fail nicely under high load?
Bjorn Stabell wrote:
Okay, I'd better explain our situation in more detail, then.
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.
If you are optimising for speed, there is nothing wrong with only making
1 catalog query, and then format the page from that. If possible.
That is basically what php base boards do anyway.
Also if the page is that dynamic, and you need that much speed, maybe
you shouldn't use zpt very much. You could generate the most critical
pages from pure Python.
That would allow for a whole different bag tricks, but still be nicer
than php.
Like caching a generated view and then replacing it vith a python
generated board view.
def re_cache(self)
self.layout_cache = self.board_template(self, self.REQUEST)
def index_html(self):
board_view = self.generate_board_view()
return self.layout_cache.replace('%%board_view%%', board_view)
regards Max M
___
Zope-Dev maillist - [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
RE: [Zope-dev] How to make Zope fail nicely under high load?
Toby wrote: 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. Storing that in ZODB would be a bad idea. Theres no reason to think that this cache would be faster than ZCatalog. I dont see why you would be *required* to store in ZODB... just dont share your cache between publisher threads on different Zope instances. (my apologies if this is obvious) Okay, for example, since it's a BBS we need to have quick access to: the latest poster the latest posting the latest registered member All of these are complex queries (in the case of the latest registered member it's not even a query but a brute-force search). What I think most ASP/PHP boards do is that they store these values in the database instead of querying for them all the time. Since many of these can be found through queries, they don't really need persistent storage, but updates need to be seen by all threads; thus the requirement for ZODB if we use ZEO, but the possibility to use (even faster) shared memory if we don't use ZEO. In effect we want to do something like this: def getLatestPoster(self): if not hasattr(self, '_v_latestPoster'): self._v_latestPoster = whatever_query() return self._v_latestPoster return self._v_latestPoster def setLatestPoster(self, poster): self._v_latestPoster = poster But instead of having thread-local variables we wanted to use Dieter Maurer's SharedResource in order to share the cache between threads: http://www.dieter.handshake.de/pyprojects/zope/SharedResource.html Regards, -- Bjorn ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] How to make Zope fail nicely under high load?
using the _v_ variables won't work for this since different threads won't agree on who was latest. Its definitely a bad idea to do queries for these three data points. What about putting them in the temp_folder then you can still use ZEO with a bunch of clients that will all share the same data but you don't need to write the values to disk every time they change. Even putting them in a normal ZODB storage would be a _lot_ faster than doing a query. -EAD On Feb 12, 2004, at 8:19 AM, Bjorn Stabell wrote: Toby wrote: 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. Storing that in ZODB would be a bad idea. Theres no reason to think that this cache would be faster than ZCatalog. I dont see why you would be *required* to store in ZODB... just dont share your cache between publisher threads on different Zope instances. (my apologies if this is obvious) Okay, for example, since it's a BBS we need to have quick access to: the latest poster the latest posting the latest registered member All of these are complex queries (in the case of the latest registered member it's not even a query but a brute-force search). What I think most ASP/PHP boards do is that they store these values in the database instead of querying for them all the time. Since many of these can be found through queries, they don't really need persistent storage, but updates need to be seen by all threads; thus the requirement for ZODB if we use ZEO, but the possibility to use (even faster) shared memory if we don't use ZEO. In effect we want to do something like this: def getLatestPoster(self): if not hasattr(self, '_v_latestPoster'): self._v_latestPoster = whatever_query() return self._v_latestPoster return self._v_latestPoster def setLatestPoster(self, poster): self._v_latestPoster = poster But instead of having thread-local variables we wanted to use Dieter Maurer's SharedResource in order to share the cache between threads: http://www.dieter.handshake.de/pyprojects/zope/SharedResource.html Regards, -- Bjorn ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope ) ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
RE: [Zope-dev] How to make Zope fail nicely under high load?
Zope should have something like ASP's Response.IsClientConnected method, which would allow app code to manually abort the processing of a request in strategic places if the connection has already been closed. I mentioned this a while back, but never did do anything about it. On Wed, 2004-02-11 at 20:05, Bjorn Stabell wrote: 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, ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
RE: [Zope-dev] How to make Zope fail nicely under high load?
Erik: using the _v_ variables won't work for this since different threads won't agree on who was latest. Its definitely a bad idea to do queries for these three data points. What about putting them in the temp_folder then you can still use ZEO with a bunch of clients that will all share the same data but you don't need to write the values to disk every time they change. Even putting them in a normal ZODB storage would be a _lot_ faster than doing a query. You're right, _v_ wouldn't work. So with temp_folder (TemporaryStorage) there is basically no need for the SharedResource product anymore? For ZEO, my understanding is that we would still have to store the values in the ZODB, though. Regards, -- Bjorn ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: How to make Zope fail nicely under high load?
Tres Seaver wrote: Bjorn Stabell wrote: 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. Impatient clients often force reloads; I don't *think* Apache has a knob which allows a surrogate / acceloerator proxy to ignore the spec (which is written assuming forward proxies), and serve from cache anyway. 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 - peter. Tres. smime.p7s Description: S/MIME Cryptographic Signature ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: How to make Zope fail nicely under high load?
Peter Sabaini wrote: Tres Seaver wrote: Bjorn Stabell wrote: 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. Impatient clients often force reloads; I don't *think* Apache has a knob which allows a surrogate / acceloerator proxy to ignore the spec (which is written assuming forward proxies), and serve from cache anyway. 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 Cool. I didn't remember that, and haven't been using Apache for caching for some while now. Thanks for the correction! Tres.. -- === Tres Seaver[EMAIL PROTECTED] Zope Corporation Zope Dealers http://www.zope.com ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] How to make Zope fail nicely under high load?
Bjorn Stabell wrote: (..)For ZEO, my understanding is that we would still have to store the values in the ZODB, though. 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. Not sure, but I'd expect so, whether this has significant perfomance advantages over a 'normal' ZODB served by the ZSS. regards, jw -- Jan-Wijbrand Kolman [EMAIL PROTECTED] ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: How to make Zope fail nicely under high load?
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. smime.p7s Description: S/MIME Cryptographic Signature ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
RE: [Zope-dev] How to make Zope fail nicely under high load?
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. Col :) 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 ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Put an adapted object in context
Santi Camps wrote: My problem is that the adapter object, and also the adapted object contained in it, are out of publisher context or something like this. For instance, absolute_url() methods doesn't work becouse REQUEST is not defined. I'm not sure I understand what you mean; I don't understand why your adapted object would become detached from the original context. It looks like you're losing acquisition context. You put an object into acquisition context explicitly. Something along these lines: import Acquisition class MyAdapter(Acquisition.Explicit): def __init__(self, context): self.context = context def getAdapter(context): # create adapter for context, and wrap it explicitly in the acquisition # context return MyAdapter(context).__of__(context) This works to give the adapter among other things a security context, so you can call methods on the adapter from a page template, for instance. You can also get to REQUEST and such, though in this case I used explicit acquisition so you'll have to use self.aq_acquire.REQUEST, if I recall the syntax correctly. Regards, Martijn P.S. In the course of the coming weeks I'll be backporting parts of Zope 3's component architecture, especially adapters, into Zope 2. Contact me if you're interested. I also expect I'll be making more noise about this in a few weeks. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: Adapters in Zope 2
Santi Camps wrote: Very interesting. That's what I was looking for. I will try to extract this mechanism from CMF. Silva has co-evolved (some of it inspired directly by CMF, some by Zope 3) much of the same infrastructure. Our view system is quite different, and some large changes to it in the coming months. We use a very simple 'service' model (equivalent to 'CMF' tools), and we've just started to use a very simple kind of adapter. Though likely less structured than the CMF it may be worthwhile taking a way to look at the way we do it in Silva. Regards, Martijn ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Adapters in Zope 2
Leonardo Rochael Almeida wrote: Acquisition is very powerful, and very magic at the same time. Adapters is Zope3 way of implementing Acquisition in a less surprising way. The main drawback of acquisition, which is a drawback in general of Zope 2, is that namespaces get conflated. Zope 2 is handling namespaces in a really unpythonic way. When you call a method the actual method can be coming from a huge range of places: * method defined by the class the object is an instance of. * method defined on a superclass of this class. In Zope 2, there are many many mixins which may be defining this method. * method defined directly on the instance in the ZODB (a Python script, for instance), if your instance is Folderish. * method acquired from object somewhere in acquisition context. These objects can have methods from their class, mixins, and directly defined if they're Folderish, of course. :) * if you're using CMF skins, method can be coming from any skin folder as well. * if you're using DTML, it can be coming from any object in your namespace stack. :) Page Templates fix the last part. Using the Silva view system (for instance) fixes the namespace conflation done by CMF skins. On the filesystem product level, you can use adapters to avoid increasing the mixin problem in your own code. We've started doing this in a simplistic fashion with Silva now, and plan to extend this use much more in the future, porting methods defined on base classes onto adapters instead. Adapters in Zope 2 are immature at present, but this will change after they've gotten properly backported from Zope 3 and such a backport is released. This is what is going to happen within the coming months, as I'm i in a project which has this as a requirement. Regards, Martijn ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Put an adapted object in context
Santi Camps wrote: My problem is that the adapter object, and also the adapted object contained in it, are out of publisher context or something like this. For instance, absolute_url() methods doesn't work becouse REQUEST is not defined. I'm not sure I understand what you mean; I don't understand why your adapted object would become detached from the original context. It was a stupid question, I was applying the adapter before publishing the object. Now I apply the adapter in __bobo_traverse__ and its beginning to run OK. It looks like you're losing acquisition context. You put an object into acquisition context explicitly. Something along these lines: import Acquisition class MyAdapter(Acquisition.Explicit): def __init__(self, context): self.context = context def getAdapter(context): # create adapter for context, and wrap it explicitly in the acquisition # context return MyAdapter(context).__of__(context) This works to give the adapter among other things a security context, so you can call methods on the adapter from a page template, for instance. You can also get to REQUEST and such, though in this case I used explicit acquisition so you'll have to use self.aq_acquire.REQUEST, if I recall the syntax correctly. Thats very interesting !! I was rewriting __getattr__ to allow the adapter access adapted object attributes, but doing this way its clear and easier. Inheriting from Acquisition Implicit and applying the adapter using __of__ I obtain the same result and have less problems. Regards, Martijn P.S. In the course of the coming weeks I'll be backporting parts of Zope 3's component architecture, especially adapters, into Zope 2. Contact me if you're interested. I also expect I'll be making more noise about this in a few weeks. Sure. Now my little adapters systems is beginning to work fine, and I will move my application this way. I'm using a simple engine, a method to define which adapters should be applied to each meta_type (this info is stored in SESSION) and then this adapters are transparently applied when accessing this kind of objects (writing some code in __bobo_traverse__). -- Santi Camps http://zetadb.sourceforge.net ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] HELP NEEDED!!!
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 idit gives an error. but when i try to give a static id for the second tableit 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___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] https with zope 2.7
A fairy clean way did exist in 2.6.x to get zope to generate https: instead of http in self referencing URLs, using Pound, and without standing on one leg and shaking a rattle at apache mod_proxy / rewrite. http://mail.zope.org/pipermail/zope/2004-February/thread.html#146614 The magic in z2.py happened by adding a new HTTPS server with: +try: +del HTTPS_ENV['HTTP'] +except KeyError: +pass +HTTPS_ENV['HTTPS']='ON' I'm not seeing an easy way to achieve the same in Zope 2.7, or perhaps I'm just not as familiar with the code yet. Could someone point me in the right direction?? Tom ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
RE: [Zope-dev] How to make Zope fail nicely under high load?
On Thu, 2004-02-12 at 07:19, Bjorn Stabell wrote: Toby wrote: 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. Storing that in ZODB would be a bad idea. Theres no reason to think that this cache would be faster than ZCatalog. I dont see why you would be *required* to store in ZODB... just dont share your cache between publisher threads on different Zope instances. (my apologies if this is obvious) Okay, for example, since it's a BBS we need to have quick access to: the latest poster the latest posting the latest registered member Create a zope product that doesn't keep a history (otherwise the ZODB will grow like nuts) and store these values in it whenever there is a new port/registration. Then just read them when you need to. Anyone see anything wrong with that approach? All of these are complex queries (in the case of the latest registered member it's not even a query but a brute-force search). What I think most ASP/PHP boards do is that they store these values in the database instead of querying for them all the time. Since many of these can be found through queries, they don't really need persistent storage, but updates need to be seen by all threads; thus the requirement for ZODB if we use ZEO, but the possibility to use (even faster) shared memory if we don't use ZEO. In effect we want to do something like this: def getLatestPoster(self): if not hasattr(self, '_v_latestPoster'): self._v_latestPoster = whatever_query() return self._v_latestPoster return self._v_latestPoster def setLatestPoster(self, poster): self._v_latestPoster = poster But instead of having thread-local variables we wanted to use Dieter Maurer's SharedResource in order to share the cache between threads: http://www.dieter.handshake.de/pyprojects/zope/SharedResource.html Regards, -- Edward Muller - http://www.interlix.com - Open Source Specialists Dedicated Zope Hosting - Web Hosting - Open Source Consulting Network PC Service Support - Custom Programming Phone: 417-862-0573 - Cell: 417-844-2435 - Fax: 417-862-0572 Jabber: [EMAIL PROTECTED] - AIM: edwardam453 - ICQ: 287033 ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] How to make Zope fail nicely under high load?
On Thu, 2004-02-12 at 10:06, Jan-Wijbrand Kolman wrote: Bjorn Stabell wrote: (..)For ZEO, my understanding is that we would still have to store the values in the ZODB, though. 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. Cool, didn't know that. Not sure, but I'd expect so, whether this has significant perfomance advantages over a 'normal' ZODB served by the ZSS. regards, jw -- Edward Muller - http://www.interlix.com - Open Source Specialists Dedicated Zope Hosting - Web Hosting - Open Source Consulting Network PC Service Support - Custom Programming Phone: 417-862-0573 - Cell: 417-844-2435 - Fax: 417-862-0572 Jabber: [EMAIL PROTECTED] - AIM: edwardam453 - ICQ: 287033 ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
