[Cypher] Execution time for cypher queries in java application

843 views
Skip to first unread message

Samwillie

unread,
May 8, 2012, 6:29:27 AM5/8/12
to Neo4j
Hi experts,

During debugging, I noticed that queries like in the example below
takes more than 10 seconds to complete - from my java web application,
even though the results are paginated - I do this:

ExecutionEngine executionEngine = new ExecutionEngine(graphDbService);
ExecutionResult result = executionEngine.execute(start n =
node:abcNodes('name:*') return n skip {skipNumber} limit {pageSize}
// it takes more than 10 seconds to reach this point...
for (Map<String, Object> row : result) {
Node n = (Node) row.values().iterator().next();
nodeList.add(n);
}

where, abcNodes is my index name.

However, the same query when executed from the Neo4j admin console, is
really fast. Is there some way to improve the query performance,
perhaps I missed something here.

Many thanks...

Andres Taylor

unread,
May 8, 2012, 6:36:36 AM5/8/12
to ne...@googlegroups.com
executionEngine.execute take 10 seconds to run? For this query, that sounds like something else is borked. Can you show us more of your code, and details on the environment you run this in?

Andrés

Peter Neubauer

unread,
May 8, 2012, 6:41:23 AM5/8/12
to ne...@googlegroups.com
Also,
are you running the Java-app in one-off tests while the server is
serving a few requests? Could that you are starting cold all the time
in your java code.

Cheers,

/peter neubauer

G:  neubauer.peter
S:  peter.neubauer
P:  +46 704 106975
L:   http://www.linkedin.com/in/neubauer
T:   @peterneubauer

If you can write, you can code - @coderdojomalmo
If you can sketch, you can use a graph database - @neo4j

Michael Hunger

unread,
May 8, 2012, 6:51:01 AM5/8/12
to ne...@googlegroups.com
Also:

- your index-size
- the values for skip and page
- you should not measure the first run but the second or third
- and not during debugging but with long start=System.currentTimeMillis() & then output (System.currentTimeMillis()-start)
- what jvm options do your run your application with (heap size, -server?)

Michael

Samwillie

unread,
May 8, 2012, 10:06:56 AM5/8/12
to Neo4j
Hi Andres, Peter and Michael,

Thanks for your time...

@Andres: I have a database containing approx 30000 nodes which is
grouped by two indexes, abcNodes and xyzNodes.
I access the locally hosted Neo4j server and access the database with
a java application running on glassfish, using
new RestGraphDatabase("local server path");

I set parameters in my query for pagination like so:
Map<String, Object> params = new HashMap<String, Object>();
params.put("skipLimit", 1);
params.put("resultsPerPage", 20);
and execute the query: executionEngine.execute(start n =
node:abcNodes('name:*') return n skip {skipLimit} limit
{resultsPerPage}", params);

@Peter: The neo4j server is locally hosted just for testing purposes.
This is a rest application deployed in glassfish - am sorry but I
didn't understand the term "starting cold"...

@Michael:

JVM settings:
-XX:MaxPermSize=256m
-Xmx1024m

Index size: don't know how to get this yet...
Values for skip and limit: 1 and 20
Running the application not in debugging mode: I get the results
Execution time for query: 6391 ms (first run)
Second time: 4965 ms
Third time: 5536 ms
Fourth time: 4448 when we paginate with 1 and 15.

Thanks...

On May 8, 12:51 pm, Michael Hunger <michael.hun...@neotechnology.com>
wrote:

Michael Hunger

unread,
May 8, 2012, 10:32:53 AM5/8/12
to ne...@googlegroups.com
Ok,

the problem is: you must _NOT_ use ExecutionEngine around a remote RestGraphDatabase but instead use

RestCypherQueryEngine engine = new RestCypherQueryEngine(restGraphDatabase.getRestAPI())
engine.query(statement, params);

otherwise: you will execute cypher locally on the client with each core-api operation going over the wire individually, you certainly don't want that !

Michael

Samwillie

unread,
May 8, 2012, 11:46:24 AM5/8/12
to Neo4j
Hi Michael,

Thanks a lot!! That was the problem - now I tested the query and I get
the results in approx. 200 milliseconds!!

This change to using RestCypherQueryEngine shouldn't normally affect
the cypher query right? Because, while other queries work, the
following query fails or hangs completely - it worked fine with the
ExecutionResult before...

QueryResult<Map<String, Object>> result =
executionEngine.query("start n = node({node}) MATCH (n)<-
[:DESIGNED_FOR]-(x) RETURN x skip {skipNumber} limit {pageSize}",
params);
for (Map<String, Object> row : result) {
Node n = (Node) row.values().iterator().next();
nodeList.add(n);
}

where DESIGNED_FOR is a relationship type.

Is there another way to write the cypher query so that it gets
executed by the RestCypherQueryEngine?

Many thanks!

On May 8, 4:32 pm, Michael Hunger <michael.hun...@neotechnology.com>

Michael Hunger

unread,
May 8, 2012, 2:00:08 PM5/8/12
to ne...@googlegroups.com
Sam,

can you look at the server logs (data/logs/console.log and data/logs/neo4j.0.0.log) to see if that query runs into any exception ?

It looks pretty straightforward and should not pose a problem. What do you pass in as parameters (node, skipNumber, pageSize) ?
perhaps passing in node.getId() as "node" will help.

Michael

Samwillie

unread,
May 9, 2012, 3:41:53 AM5/9/12
to Neo4j
Hi Michael,

Thanks a lot! Passing in node.getId() works!!!

Yes, I pass in node, skipNumber and pageSize as parameters. The
RestCypherQueryEngine needs the nodeId to passed as parameter, whereas
the Execution engine just needs the node! That was the difference.

And there were no entries in the logs - it just stays as if nothing
happened, except I get a cannot connect to server error - read timed
out message.

The only log message, that I found as usual was the following, But
everything works normal.

WARNING: Could not lock User prefs. Unix error code 2.
09.05.2012 09:35:43 java.util.prefs.FileSystemPreferences syncWorld
WARNING: Couldn't flush user prefs:
java.util.prefs.BackingStoreException: Couldn't get file lock.

Many thanks to all of you again!

Greets,



On May 8, 8:00 pm, Michael Hunger <michael.hun...@neotechnology.com>
Reply all
Reply to author
Forward
0 new messages