Home » Eclipse Projects » EclipseLink » EclipseLink read performance issue with MongoDB
| EclipseLink read performance issue with MongoDB [message #1719854] |
Tue, 12 January 2016 10:43  |
Eclipse User |
|
|
|
Hi,
I've been looking at the performance of EclipseLink with a NoSQL DB, more specifically MongoDB.
This is more out of interest to quickly asses the performance of EclipseLink. I've done this using random JPA entityManager reads, on a fully populated database with 1 million records.
When conducting 1 million read operations on this database, or actually any large number of ops (e.g. 100k ops) I've noticed a strange pattern in the distribution of the latency of the read operation. (see below)
Here's an example of my read operation:
public int read(String key) {
EntityManager em = emf.createEntityManager();
User u = em.find(User.class, key);
if(amountOps++ % clearOps == 0)
em.clear();
em.close();
}
So the read is very basic, and works just fine.
The EM cache is being cleared after 1.000 ops, but this should not matter too much as the EM is closed after each read.
However lets look at the latency of the read operations in the case of 1 million reads on a database with 1 million records.
[READ], 0, 960693
[READ], 1, 697
[READ], 2, 88
[READ], 3, 497
[READ], 4, 1419
[READ], 5, 3111
[READ], 6, 4061
[READ], 7, 4311
[READ], 8, 4530
[READ], 9, 4439
[READ], 10, 4359
[READ], 11, 4216
[READ], 12, 3530
[READ], 13, 1984
[READ], 14, 714
[READ], 15, 257
[READ], 16, 123
[READ], 17, 93
[READ], 18, 69
What [READ],6 for example means is how many read operations took between 6-7 ms to complete.
So the majority of the reads (960.000) take less then 1 ms to complete on a remote database cluster, which is just fine.
I would expect a decreasing amount of operations in correlation with the latency.
In this case the amount of read operations taking between 1-2 and 2-3ms decreases, but then increases again.
This is behaviour I would normally not expect.
For example there are 4311 reads taking between 7 and 8 ms, while there are only 697 reads taking between 1 and 2 ms.
Furthermore to assess the base performance I've disabled caching.
You can see this in my persistence.xml file listed below:
<persistence-unit name="eclipselink-mongodb" transaction-type="RESOURCE_LOCAL">
<class>User</class>
<properties>
<property name="eclipselink.target-database" value="org.eclipse.persistence.nosql.adapters.mongo.MongoPlatform"/>
<property name="eclipselink.nosql.connection-spec" value="org.eclipse.persistence.nosql.adapters.mongo.MongoConnectionSpec"/>
<property name="eclipselink.nosql.property.mongo.port" value="27017"/>
<property name="eclipselink.nosql.property.mongo.host" value="..."/>
<property name="eclipselink.nosql.property.mongo.db" value="eclipselink"/>
<property name="eclipselink.logging.level" value="OFF"/>
<property name="org.eclipse.persistence.config.CacheUsage" value="DoNotCheckCache" />
<property name="eclipselink.cache.shared.default" value="false"/>
<property name="eclipselink.cache-usage" value="DoNotCheckCache" />
<property name="eclipselink.connection-pool.max" value="1" />
</properties>
</persistence-unit>
So in conclusion, the majority of the reads actually happen very fast. But a large fraction (~5%) decide to take a lot longer.
Are there any possible explanations to why this is happening?
Because in my opinion I think EclipseLink is quite fast, but there's just something influencing reads at random times in a consistent manner.
My first idea would that it may be the cache, but I think that can't be the case since it is disabled.
The load on the cluster can also be taken out of the equation, since it's a dedicated setup just to test this.
I've also tested it quickly for another JPA-implementation and it did match my expectations perfectly there.
Any thoughts?
|
|
| | |
Goto Forum:
Current Time: Mon Jul 28 10:32:46 EDT 2025
Powered by FUDForum. Page generated in 0.24153 seconds |
Home