Re: [Zope-dev] Do I really understanding caching?
Andy McKay wrote: What problem are you trying to solve -- response time, memory usage, disk usage? All of the above :) Describe some of the symptoms back on the list and let's talk about it there. For instance, you can trade RAM for performance by adjusting knobs on the catalog. --Paul ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Do I really understanding caching?
Andy McKay wrote: We have been looking at caching in Zope as a way of tweaking performance. Heres an example of what I think happens: - Supposing I have a 1,000 object catalog. If one person changes an catalog aware object, that instance of the catalog will be pulled out of the ZODB and changed. It will then be written to the ZODB. That last copy will stay in the cache for as long as the "Cache Parameters" are set to allow. - If somebody changes another catalog aware object, that will repeat the above process. - However simply accessing the catalog (no changes) will pull the object from the cache. - What would be really nice is if the object only got written to the cache when it is no longer used, that way every time the catalog changed it didnt write to ZODB instead it changed the cached version. Of course that does bring up the recovering from disaster problem. So do I understand it correctly? Not exactly. Have you seen the ZODB paper? http://www.zope.org/Members/jim/Info/IPC8/ZODB3 You can think of the normal ZODB cache as being a tool that manages the objects in memory. Whenever an object has been accessed, it is in the cache. The cache, together with the database are responsible for moving objects, and their state in and out of memory. An object can be in serveral in memory states. Two that are of interest, from a caching perspective, are the "ghost" state and the up-to-date state. The up-to-date state is a state in which the object and it's state are loaded. In the ghost state, the object is in memory, but it has now state. The cache manager tries to release an object's state and remove the object from memory when it is not used. An object's state is released when it hasn't been accessed in a long time. It can be removed when no other objects (not counting the cache itself) refer to it. Note that the cache parameters are only guides for an algorithm that is somewhat adaptive and a bit more complicated than the parameters suggest. For example, the target cache size is a target, not a limit. The cache sizes are usually mich higher than the target. Another thing to be aware of is that large objects are generally designed to spread their state over many subobjects so that they can make effective use of the cache. A catalog may have hundreds of sub-objects, only a small fraction of which are kept in memory at a time. Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Technical Director (888) 344-4332 Python Powered! Digital Creationshttp://www.digicool.com http://www.python.org Under US Code Title 47, Sec.227(b)(1)(C), Sec.227(a)(2)(B) This email address may not be added to any commercial mail list with out my permission. Violation of my privacy with advertising or SPAM will result in a suit for a MINIMUM of $500 damages/incident, $1500 for repeats. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Membership and Local Roles
Michael Bernstein wrote: Michael Bernstein wrote: I figured out how to get this to work (finally). In the acl_users LM, add the following two Python methods: Well, I discovered another problem: For some reason, when I create a PortalMembership member, add the two Python methods as I described earlier, and use the local roles screen to give them a role, they are subsequently authenticated regardless of whether their password is correct. Here's an example illustrating the bug: [snip example] This password problem is fixed with Bill Andersons new release of Membership 0.7.6, so the local roles fix now works generally. There is still a platform dependent password problem with Membership though. It affects Solaris and HPUX (possibly other unices) but not Linux, and has to do with the crypt module not being loaded correctly on those platforms, causing passwords to be encrypted omly part of the time. Here is the fix for local roles: First, the User Source needs to support a getUserNames method. This can be done two ways: You can add a Python method to the LoginManager named getUserNames that takes a 'self' parameter, and has the following body: user_ids=self.UserSource.getPersistentItemIDs() names=[] for i in user_ids: names.append(i) return names Or you can add the following code directly to the PersistentUserSource.py file, preferably right befor or after the getUsers method: def getUserNames(self): user_ids=self.getPersistentItemIDs() names=[] for i in user_ids: names.append(i) return names (I hope this will get included in future versions of Membership) Next we need to provide a user_names method in the LoginManager. Currently I only have a Python method to drop in to the LM. it takes a 'self' parameter, and has the following body if it's calling another Python method: return self.getUserNames() Or if you're calling the method in PersistentUserSource.py, it has this body: return self.UserSource.getUserNames() Note that this user_names method has some disadvantages, and it needs to be generalized to deal with multiple User Sources that aren't all named UserSource, and that may not all implement the getUserNames interface, and that may have duplicate user names in them. Suggestions on how to do this would be welcome. I hope that this little set of instructions helps others who are trying to integrate LM with the existing security interface and local roles. Comments, testing, and improvements would be welcomed. HTH, Michael Bernstein. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
