News: Databen.ch - Persistence Benchmark for the JVM
The first result of the databen.ch project is available. It uses a simple financial system model to test persistence frameworks scalability and consistency. The project core is implemented in Scala. An Amazon EC2 hi1.4xlarge instance is used for the execution and the AMI (Amazon Image) is published with the results. There are implementations for the Java frameworks: BatooJpa, Db4o, Ebean, EcliseLink, Hibernate and Prevayler. Also for the Scala frameworks: Activate, Slick and Squeryl. The project is open to receive pull requests and suggestions to enhance the current implementations. http://databen.ch
- Posted by: Flavio Brasil
- Posted on: April 09 2013 10:09 EDT
Flavio - Very interesting, but you probably should have added: "In the interest of full disclosure, Activate is maintained by Flávio W. Brasil." So out of curiosity, how do you explain the performance differences? For example, what gives Activate an edge in this test versus the various JPA implementations? I also thought it was interesting that Postgres under Activate was significantly faster than MongoDB under Activate. Any comments on that? Peace, Cameron Purdy | Oracle (In the interest of full disclosure, the EclispeLink and the JPA teams are both in my group.)
Wow, it screwed with my formatting pretty badly!
Hi Peace. Information added to the "Fairness" page. Thanks for the suggestion. There are two main reasons for the Activate scalability: efficient memory usage and in-memory optimistic locking. The efficient memory usage reduces the conversation with the database and the in-memory optimistic locking can detect transaction conflicts without having to do a database trip. These characteristics are possible because the framework is a Distributed Durable STM. I also found interesting the Mongo results. It is fast, but with scalability limitation. Researching, looks like it can't scale well because of the use of pessimistic locks on the database and/or collection when writing to it. The best PostgreSQL result uses 5 VMs with 13 threads against 1 VM with 7 threads of the Mongo result.