Hedley Roos wrote:
Since memcached is distributed only a single Zope client needs to
perform that query and the result is available to all other Zope
clients.
This is where you'll get the big win: no need to load all the
catalog-related objects into the zodb cache on all the clients which
On Sun, 2008-10-26 at 14:07 -0400, Tres Seaver wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Roché Compaan wrote:
On Sat, 2008-10-25 at 09:20 +0200, Hedley Roos wrote:
Have you measures the time needs for some standard ZCatalog queries
used with a Plone site with the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Oct 27, 2008, at 13:08 , Roché Compaan wrote:
On Sun, 2008-10-26 at 14:07 -0400, Tres Seaver wrote:
- Plone uses too many indexes, and in particular, uses multiple text
indexes. Having extra indexes around just in case is a sure lose
a
On Mon, 2008-10-27 at 13:23 +0100, Jens Vagelpohl wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Oct 27, 2008, at 13:08 , Roché Compaan wrote:
On Sun, 2008-10-26 at 14:07 -0400, Tres Seaver wrote:
- Plone uses too many indexes, and in particular, uses multiple text
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Oct 27, 2008, at 13:32 , Roché Compaan wrote:
On Mon, 2008-10-27 at 13:23 +0100, Jens Vagelpohl wrote:
When it comes to integrating anything in Zope itself I'd choose the
latter.
Sure, we're not trying to get this into Zope, we're just
On Mon, 2008-10-27 at 13:41 +0100, Jens Vagelpohl wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Oct 27, 2008, at 13:32 , Roché Compaan wrote:
On Mon, 2008-10-27 at 13:23 +0100, Jens Vagelpohl wrote:
When it comes to integrating anything in Zope itself I'd choose the
On Mon, Oct 27, 2008 at 12:33 PM, Andreas Jung [EMAIL PROTECTED] wrote:
On 27.10.2008 16:28 Uhr, Rudá Porto Filgueiras wrote:
I will sugest a package called zope.memcached (like zope.sqlalchemy
does for SQLAlchemy integration).
That way any application who need to talk memcached can do it
On 27.10.2008 17:18 Uhr, Rudá Porto Filgueiras wrote:
On Mon, Oct 27, 2008 at 12:33 PM, Andreas Jung[EMAIL PROTECTED] wrote:
On 27.10.2008 16:28 Uhr, Rudá Porto Filgueiras wrote:
I will sugest a package called zope.memcached (like zope.sqlalchemy
does for SQLAlchemy integration).
That way
On 26.10.2008 18:43 Uhr, Roché Compaan wrote:
On Sat, 2008-10-25 at 09:20 +0200, Hedley Roos wrote:
I suspect specific indexes are just performing suboptimally and needs to
be improved. ExtendPathIndex in Plone seems to be one of them.
Path indexes and fulltext indexes have a much more
Hi Roché,
I can see your funkload profile?
On Sun, Oct 26, 2008 at 3:43 PM, Roché Compaan
[EMAIL PROTECTED]wrote:
On Sat, 2008-10-25 at 09:20 +0200, Hedley Roos wrote:
Have you measures the time needs for some standard ZCatalog queries
used with a Plone site with the communication
Hi Fabio
The funkload tests were project specific. I plan to write up my findings
and to do benchmarks on a standard Plone instance and blog about it.
This will unfortunately have to wait since I'm on holiday this week :-)
--
Roché Compaan
Upfront Systems
On Sun, 2008-10-26 at 18:50 +0100, Andreas Jung wrote:
On 26.10.2008 18:43 Uhr, Roché Compaan wrote:
On Sat, 2008-10-25 at 09:20 +0200, Hedley Roos wrote:
I suspect specific indexes are just performing suboptimally and needs to
be improved. ExtendPathIndex in Plone seems to be one of
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Roché Compaan wrote:
On Sat, 2008-10-25 at 09:20 +0200, Hedley Roos wrote:
Have you measures the time needs for some standard ZCatalog queries
used with a Plone site with the communication overhead with memcached?
Generally spoken: I think the
Very Nice.
Have a nice holiday :-)
On Sun, Oct 26, 2008 at 3:58 PM, Roché Compaan
[EMAIL PROTECTED]wrote:
Hi Fabio
The funkload tests were project specific. I plan to write up my findings
and to do benchmarks on a standard Plone instance and blog about it.
This will unfortunately have to
On 26.10.2008 19:05 Uhr, Roché Compaan wrote:
On Sun, 2008-10-26 at 18:50 +0100, Andreas Jung wrote:
On 26.10.2008 18:43 Uhr, Roché Compaan wrote:
On Sat, 2008-10-25 at 09:20 +0200, Hedley Roos wrote:
I suspect specific indexes are just performing suboptimally and needs to
be improved.
The usual Plone catalogs (portal_catalog, uid_catalog,
reference_catalog and membrane_tool) all run above 90% hit rate if the
server is up to it. portal_catalog is invalidated the most so it
fluctuates the most.
If the server is severely underpowered then catalogcache is much less
effective.
On 25.10.2008 8:48 Uhr, Hedley Roos wrote:
The usual Plone catalogs (portal_catalog, uid_catalog,
reference_catalog and membrane_tool) all run above 90% hit rate if the
server is up to it. portal_catalog is invalidated the most so it
fluctuates the most.
If the server is severely underpowered
Have you measures the time needs for some standard ZCatalog queries
used with a Plone site with the communication overhead with memcached?
Generally spoken: I think the ZCatalog is in general fast. Queries using a
fulltext index are known to be more expensive or if you have to deal with
large
Hedley Roos wrote:
As for standard queries on a Plone site the typical folder contents
query is a good example. The query will be fast unless it sorts on
sortable_title (a ZCTextIndex) right? Not sure right now.
sortable_title is a field index and shouldn't be slower than any other
index.
Hi,
On Fri, 2008-10-24 at 15:41 +0200, Hedley Roos wrote:
The product is a monkey patch to Catalog.py. I'd love some feedback and
suggestions.
I'd love if this wouldn't be a monkey patch.
Also, there is nothing that makes this integrate correctly with
transactions. Your cache will happily
I'd love if this wouldn't be a monkey patch.
So would I, but I couldn't find another way in this case.
Also, there is nothing that makes this integrate correctly with
transactions. Your cache will happily deliver never-committed data and
also it will not isolate transactions from each
In addition, you need to include a serial in your cache keys to avoid
dirty reads.
The cache invalidation code actively removes items from the cache. Am
I understanding you correctly?
H
___
Zope-Dev maillist - Zope-Dev@zope.org
On 25.10.2008 14:53 Uhr, Hedley Roos wrote:
I'd love if this wouldn't be a monkey patch.
So would I, but I couldn't find another way in this case.
Also, there is nothing that makes this integrate correctly with
transactions. Your cache will happily deliver never-committed data and
also it
On Sat, 2008-10-25 at 14:53 +0200, Hedley Roos wrote:
I'd love if this wouldn't be a monkey patch.
So would I, but I couldn't find another way in this case.
Also, there is nothing that makes this integrate correctly with
transactions. Your cache will happily deliver never-committed
On Sat, Oct 25, 2008 at 2:57 PM, Andreas Jung [EMAIL PROTECTED] wrote:
On 25.10.2008 14:53 Uhr, Hedley Roos wrote:
I'd love if this wouldn't be a monkey patch.
So would I, but I couldn't find another way in this case.
Also, there is nothing that makes this integrate correctly with
If you catalog an object, then search for it and then abort the
transaction, your cache will have data in it that isn't committed.
Kind of like how I came to the same conclusion in parallel to you and
stuffed up this thread :)
Additionally when another transaction is already running in
Additionally when another transaction is already running in parallel, it
will see cache inserts from other transactions.
A possible solution is to keep a module level cache which can be
committed to the memcache on transaction boundaries. That way I'll
incur no performance penalty.
H
On Sat, 2008-10-25 at 14:55 +0200, Hedley Roos wrote:
In addition, you need to include a serial in your cache keys to avoid
dirty reads.
The cache invalidation code actively removes items from the cache. Am
I understanding you correctly?
I wasn't even talking about invalidation as your
Hi all
The past few weeks I've been optimizing a busy Plone site and so
collective.catalogcache was born.
It uses memcached as a distributed ZCatalog cache. It is currently in
production and seems to be holding just fine. The site went from being
unusable to serving quite a bit of data.
I'll
29 matches
Mail list logo
