Shane Hathaway wrote:
> RelStorage currently uses memcached in a very simple way: it puts (tid,
> state) in the cache for each oid. When RelStorage reads from the cache,
> if it gets a state for a different transaction than the transaction ID
> last polled by the storage instance, RelStorage di
Jim Fulton wrote:
> On Wed, Oct 14, 2009 at 2:48 PM, Shane Hathaway wrote:
>> When ZODB is unpickling the state of an object, it often has to pull in
>> several objects, one at a time.
>
> Several object references.
Ah yes, and the class info for those object references is usually stored
in the
On Wed, Oct 14, 2009 at 2:48 PM, Shane Hathaway wrote:
> Jim Fulton wrote:
...
>> The biggest problem with ZEO performance on the client side is that
>> reads require round trips and that generally a client thread only
>> knows to request one read at a time [1]_. I plan to add an API for
>> async
Jim Fulton wrote:
> The most complicated logic in the ZEO cache, which would be just as
> complicated with another cache storage implementation and more
> complicated with a shared cache storage is making sure the cache
> doesn't have stale state. I probably need to look at memcache again,
> but e
On Tue, Oct 13, 2009 at 8:30 PM, Shane Hathaway wrote:
> This leads to an interesting question. Memcached or ZEO cache--which is
> better?
For what? For relstorage? or for ZEO?
> While memcached has a higher minimum performance penalty, it
> also has a lower maximum penalty, since memcached hit
