Re: [ZODB-Dev] ZEO and relstporage performance
On Tue, Oct 13, 2009 at 06:30:31PM -0600, Shane Hathaway wrote: Laurence Rowe wrote: Shane's earlier benchmarks show MySQL to be the fastest RelStorage backend: http://shane.willowrise.com/archives/relstorage-10-and-measurements/ Yep, despite my efforts to put PostgreSQL on top. :-) It seems that PostgreSQL has more predictable performance and behavior, while MySQL wins slightly in raw performance once every surprisingly slow query has been optimized. The usual wisdom on that is MySQL is faster at raw table reading, PostgreSQL at concurrency, esp. w/ any writing thrown in. Often, the performance curves 'cross' at some point. Could be 16 in this case. For my druthers, I just _trust_ PostgreSQL a lot more: the one MySQL DB I have that I use on an on-going basis is my MythTV media-pc. Once a month or so I have to repair a table. I've used PostgreSQL in professional high load production for years and never had a corruption issue: even when running out of disk! (the main culprit in my experience w/ MySQL, since that's the default state for a PVR: full!) snip caching discussion This leads to an interesting question. Memcached or ZEO cache--which is better? While memcached has a higher minimum performance penalty, it also has a lower maximum penalty, since memcached hits never have to wait for disk. Also, memcached can be shared among processes, there is a large development community around memcached, and memcached creates opportunities for developers to be creative with caching strategies. shared caches: this is the main reason I've been looking at relstore: we're running many Zope FEs against one ZOE right now, and due to the nature of the load-balancer, we're seeing little gain from the caches. I'm looking to fix that issue, to some extent, but sharing across all the FEs on one box would be a big win, I'm sure. So I'm inclined to stick with memcached even though the ZEO cache numbers look better. Ross -- Ross Reedstrom, Ph.D. reeds...@rice.edu Systems Engineer Admin, Research Scientistphone: 713-348-6166 The Connexions Project http://cnx.orgfax: 713-348-3665 Rice University MS-375, Houston, TX 77005 GPG Key fingerprint = F023 82C8 9B0E 2CC6 0D8E F888 D3AE 810E 88F0 BEDE ___ For more information about ZODB, see the ZODB Wiki: http://www.zope.org/Wikis/ZODB/ ZODB-Dev mailing list - ZODB-Dev@zope.org https://mail.zope.org/mailman/listinfo/zodb-dev
Re: [ZODB-Dev] ZEO and relstporage performance
Ross J. Reedstrom wrote: For my druthers, I just _trust_ PostgreSQL a lot more: the one MySQL DB I have that I use on an on-going basis is my MythTV media-pc. Once a month or so I have to repair a table. I've used PostgreSQL in professional high load production for years and never had a corruption issue: even when running out of disk! (the main culprit in my experience w/ MySQL, since that's the default state for a PVR: full!) I've had similar experiences. shared caches: this is the main reason I've been looking at relstore: we're running many Zope FEs against one ZOE right now, and due to the nature of the load-balancer, we're seeing little gain from the caches. I'm looking to fix that issue, to some extent, but sharing across all the FEs on one box would be a big win, I'm sure. I hope so. I must admit that I don't have great confidence in the probable cache hit rate of the current RelStorage/memcached strategy. I do have a lot of hope that it can be improved, possibly by adding to memcached. Shane ___ For more information about ZODB, see the ZODB Wiki: http://www.zope.org/Wikis/ZODB/ ZODB-Dev mailing list - ZODB-Dev@zope.org https://mail.zope.org/mailman/listinfo/zodb-dev
Re: [ZODB-Dev] ZEO and relstporage performance
On Wed, Oct 14, 2009 at 02:20:50PM -0400, Benji York wrote: On Wed, Oct 14, 2009 at 1:08 PM, Ross J. Reedstrom reeds...@rice.edu wrote: shared caches: this is the main reason I've been looking at relstore: we're running many Zope FEs against one ZOE right now, and due to the nature of the load-balancer, we're seeing little gain from the caches. I'm looking to fix that issue, to some extent, but sharing across all the FEs on one box would be a big win, I'm sure. For similar reasons I've been considering various affinity approaches lately. Most people are familiar with session affinity, but I'm thinking of something more like data affinity. Instead of having a big cache that is shared in order to increase the chance of a request's data being in the cache, you would instead have many smaller caches (just like ZEO works now) and send the requests to the process(es) that are most likely to have the appropriate data in their cache. We're actually set up w/ squid in front of the zope FEs, using IPC to talk to them all. The default behavior is just to respond w/ a CACHE MISS and use network access timings to select. This is non-optimal, since it does little true load-balancing, until the FE is completely hammered (very non-linear response-time curve). I'd love to see an example where someone replaced the default response w/ something more meaningful. The shoal that replying HIT' for ZEO cached data breaks on is that the IPC request contains a URL, not ZODB object refs. And converting one to the other is what the whole dang machine _does_. And you have very little time to answer that IPC query, lest you destroy the gains you hope to get from having a hot-cache. So some ad-hoc approximation, like keeping the last couple hundred URLs served, and responding 'HIT' for those, might get some part of the benefit. This is probably the wrong list for it, but does anyone know of a published example of replacing Zope's default icp-server response? Last time I looked, I couldn't find one. Ross -- Ross Reedstrom, Ph.D. reeds...@rice.edu Systems Engineer Admin, Research Scientistphone: 713-348-6166 The Connexions Project http://cnx.orgfax: 713-348-3665 Rice University MS-375, Houston, TX 77005 GPG Key fingerprint = F023 82C8 9B0E 2CC6 0D8E F888 D3AE 810E 88F0 BEDE ___ For more information about ZODB, see the ZODB Wiki: http://www.zope.org/Wikis/ZODB/ ZODB-Dev mailing list - ZODB-Dev@zope.org https://mail.zope.org/mailman/listinfo/zodb-dev
Re: [ZODB-Dev] ZEO and relstporage performance
On Wed, Oct 14, 2009 at 3:38 PM, Ross J. Reedstrom reeds...@rice.edu wrote: On Wed, Oct 14, 2009 at 02:20:50PM -0400, Benji York wrote: We're actually set up w/ squid in front of the zope FEs, using IPC to talk to them all. The default behavior is just to respond w/ a CACHE MISS and use network access timings to select. This is non-optimal, since it does little true load-balancing, until the FE is completely hammered (very non-linear response-time curve). I'd love to see an example where someone replaced the default response w/ something more meaningful. You'd probably be interested in the last four paragraphs of http://benjiyork.com/blog/2008/03/icp-for-faster-web-apps.html. The shoal that replying HIT' for ZEO cached data breaks on is that the IPC request contains a URL, not ZODB object refs. And converting one to the other is what the whole dang machine _does_. Right, but in many situations you can guess effectively. See below. And you have very little time to answer that IPC query, lest you destroy the gains you hope to get from having a hot-cache. So some ad-hoc approximation, like keeping the last couple hundred URLs served, and responding 'HIT' for those, might get some part of the benefit. I'm thinking about something more specific. For example, lets say that your data is a dictionary application and URLs are of the structure: my-site.com/WORD, where word is the word you want to show the definition of. If you generate an IPC HIT if the process has served a word beginning with the same letter recently, then particular letters will begin to be associated with particular servers, increasing the ZEO (and ZODB) cache hit rates. If you take this a step further and design your app so that you load all the words that start with a letter as one giant object, you'll get an even greater effect. (Note that in real life that object would be too giant, but you get the idea.) This is probably the wrong list for it, but does anyone know of a published example of replacing Zope's default icp-server response? Last time I looked, I couldn't find one. Other than my blog post and zc.icp the only other ICP and Zope info I know of is http://www.zope.org/Members/htrd/icp/intro (very old). Note that I haven't used zc.icp in a long time because we decided to move away from ICP and (eventually) move to a load balancer that implements our desired policy instead. -- Benji York Senior Software Engineer Zope Corporation ___ For more information about ZODB, see the ZODB Wiki: http://www.zope.org/Wikis/ZODB/ ZODB-Dev mailing list - ZODB-Dev@zope.org https://mail.zope.org/mailman/listinfo/zodb-dev
