In our stack, we use neo4j and have encountered classical performance issues : application is slow as hell as soon as it requires data from neo4j.
Listening only my courage (pun intended) I started JVisualVM and done a profiling of application.
This application is hosted in a JavaEE server (Glassfish) and uses a quasi-semantic stack made of Empire-RDF, Blueprints, and neo4j. Access to neo4j is offered by JCA neo4j-connector.
Like this screenshot suggests, there is strong evidence that there is a bottleneck in neo4j data retrieval.
My question is double, but simple.
- Is that performance level normal ? (I guess no)
- What can I do to improve those performances ?
EDIT here are some informations regarding the test procdure that should enlighten both of you.
My graph structure is, to me, unknown : as I’m using Empire-RDF on top of Blueprints/Sesame/Neo4J, I only know the Java objects I’m manipulating, which are ten intereconnected classes, and they unfortunatly are at the very core of our buisness, so I can’t disclose them.
Consider, for the sake of this example, they create a tree of visual elements linked to entities representing URI targets.
I have a maven test that runs a combination of read/write operation (I will say there is between 20 and 50 JPA operations involved). This maven test runs in 300 seconds.
On a lower level,
- application is run on Windows-7 and Mac OS X 10.6, with various sub-versions of Java 1.6.
- Application is hosted on a Glassfish 3.1.1
- neo4j DB is version 1.5, accessed through neo4j-connector for JCA (there is no customization made to default settings).
- Sesame is version 2.6.0
- blueprints is version 1.1
- Empire-RDF is version 0.7
As a last world, diving into jVisualVM sampler reveals most of the application time is spent in those NodeManager#getNodeForProxy calls.
OK, time to put an end to that joke, and thanks to both Mike who helped me.
Performance problem was not neo4J 1.5 fault, nor Empire, neither Blueprints one, but rather my poor understanding of my own persistence stack.
Do you remember I said used neo4j instance was obtained from a JCA connector ?
Well, I used version 0.2 of that connector, which worked with neo4j 1.4 … Yes, 1.4 !
Fortunatly, I already had prepared an upgrade of that version, allowing me to send parameters directly to neo4j (like setting cache_type). So I finished that upgrade, bundled it, deployed it to my local repository, integrated it into my domain, tested, and … success ! a x20 improvement of performances !