Re: [ZODB-Dev] [announce] NEO 1.0 - scalable and redundant storage for ZODB
Le 08/29/12 15:54, Leonardo Santagada a écrit : > On Mon, Aug 27, 2012 at 9:37 AM, Vincent Pelletier wrote: >> We've just tagged the 1.0 NEO release. > > any plans to support pypy in NEO? We're looking at pypy from time to time but there are at least 3 reasons preventing us to use it for NEO: - sqlite3 is still significantly slower on pypy so it could not be used for SQLite backend. I've just tested the example on https://bugs.pypy.org/issue1070 with version 1.9.0 and it's more than 2 times slower and what is suggested on https://bugs.pypy.org/msg3088 does not help. - MySQLdb is C module. We'd have to use another library for MySQL backend but that should be quick to implement. - For the client part, as you say, it depends on ZODB. So it should be possible to use pypy with admin/master/storage nodes and maybe get better performance with MySQL backend. > Once ZODB start to run on pypy it > would be cool to have relstorage/zeo or neo running on it as well. > Julien ___ For more information about ZODB, see http://zodb.org/ ZODB-Dev mailing list - ZODB-Dev@zope.org https://mail.zope.org/mailman/listinfo/zodb-dev
Re: [ZODB-Dev] [announce] NEO 1.0 - scalable and redundant storage for ZODB
On Mon, Aug 27, 2012 at 9:37 AM, Vincent Pelletier wrote: > We've just tagged the 1.0 NEO release. any plans to support pypy in NEO? Once ZODB start to run on pypy it would be cool to have relstorage/zeo or neo running on it as well. -- Leonardo Santagada ___ For more information about ZODB, see http://zodb.org/ ZODB-Dev mailing list - ZODB-Dev@zope.org https://mail.zope.org/mailman/listinfo/zodb-dev
Re: [ZODB-Dev] [announce] NEO 1.0 - scalable and redundant storage for ZODB
On Tue, Aug 28, 2012 at 12:31 PM, Vincent Pelletier wrote: ... > I forgot in the original mail to mention that NEO does all conflict > resolutions on client side rather than server side. The same happens in > relStorage, but this is different from ZEO. That's good. I'd like to move ZEO in this direction. I'd also like to stop hanging conflict-resolution on classes and have some kind of registry, so that people can set CR policies independent of class implementation. I didn't realize that relstorage did client side CR, but thinking about it, it has to work that way, since there's no relstorage server. Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton Jerky is better than bacon! http://zo.pe/Kqm ___ For more information about ZODB, see http://zodb.org/ ZODB-Dev mailing list - ZODB-Dev@zope.org https://mail.zope.org/mailman/listinfo/zodb-dev
Re: [ZODB-Dev] [Zope-dev] [announce] NEO 1.0 - scalable and redundant storage for ZODB
On Wed, Aug 29, 2012 at 2:29 AM, Marius Gedminas wrote: > On Tue, Aug 28, 2012 at 06:31:05PM +0200, Vincent Pelletier wrote: >> On Tue, 28 Aug 2012 16:31:20 +0200, >> Martijn Pieters wrote : >> > Anything else different? Did you make any performance comparisons >> > between RelStorage and NEO? >> >> I believe the main difference compared to all other ZODB Storage >> implementation is the finer-grained locking scheme: in all storage >> implementations I know, there is a database-level lock during the >> entire second phase of 2PC, whereas in NEO transactions are serialised >> only when they alter a common set of objects. > > This could be a compelling point. I've seen deadlocks in an app that > tried to use both ZEO and PostgreSQL via the Storm ORM. (The thread > holding the ZEO commit lock was blocked waiting for the PostgreSQL > commit to finish, while the PostgreSQL server was waiting for some other > transaction to either commit or abort -- and that other transaction > couldn't proceed because it was waiting for the ZEO lock.) This sounds like an application/transaction configuration problem. To avoid this sort of deadlock, you need to always commit in a a consistent order. You also need to configure ZEO (or NEO) to time-out transactions that take too long to finish the second phase. I don't think NEO's locking strategy mitigates the deadlock problem much, if at all. The strategy should provide greater transaction throughput and reduce latency. It's a strategy I'd like to implement for ZEO at some point. Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton Jerky is better than bacon! http://zo.pe/Kqm ___ For more information about ZODB, see http://zodb.org/ ZODB-Dev mailing list - ZODB-Dev@zope.org https://mail.zope.org/mailman/listinfo/zodb-dev
