Do you have some nodes in your dataset which has loads of relationships? Because if that's the case then the slow query could possible hit one or more of those "heavy" nodes.
Also are you using breadth first traversal from one direction or from both directions (both directions being much more efficient because less nodes/relationships would have to be traversed)?. Have you tried using graph-algo component <http://components.neo4j.org/neo4j-graph-algo/>? F.ex. the shortest path example on that component site is an efficient algorithm which traversed from both sides (start and end) and see where they meet. 2010/11/16 Andreas Kollegger <[email protected]> > It's possible that you're seeing a GC spike. Would you mind adding GC > monitoring[1] to your output to see if that is related? > > Best, > Andreas > > [1] > http://www.oracle.com/technetwork/java/gc-tuning-5-138395.html#0.0.0.Measurement%7Coutline > > On Nov 16, 2010, at 8:09 PM, Rick Bullotta wrote: > > > My first guess with that big a difference would be a bug in the > > calculation/output of the benchmark timing! > > > > -----Original Message----- > > From: [email protected] [mailto:[email protected]] > On > > Behalf Of Martin Grimmer > > Sent: Tuesday, November 16, 2010 4:47 AM > > To: [email protected] > > Subject: [SPAM] [Neo4j] strange performance > > > > Hello, > > > > currently we evaluate Neo4j for one of our projects. > > Our tests showed some strange behaviour to us: > > > > ... > > at query 941/10000000 (0,009410) with 1809 mb in 0,300000 seconds - > > avg: 0,308696 - max: 54,533000 > > at query 942/10000000 (0,009420) with 1809 mb in 0,069000 seconds - > > avg: 0,308441 - max: 54,533000 > > at query 943/10000000 (0,009430) with 1809 mb in 0,057000 seconds - > > avg: 0,308174 - max: 54,533000 > > at query 944/10000000 (0,009440) with 1809 mb in 0,038000 seconds - > > avg: 0,307888 - max: 54,533000 > > at query 945/10000000 (0,009450) with 1809 mb in 0,630000 seconds - > > avg: 0,308229 - max: 54,533000 > > at query 946/10000000 (0,009460) with 1809 mb in* 60,997000 seconds* > > - avg: 0,372450 - max: 60,997000 > > ... fast again > > > > Our Neo4j database is about 9 GB in size with about 130M arcs and 15M > > nodes. > > A query gets two strings as input, these are keys for the lucene index > > service to get access to two nodes. Then we start > > an algorithm for these two nodes which determines nodes which are > > adjacent (by 2 steps BFS) to both restricted to only one specific arc > type. > > I dont know why some queries are so much (> x100) slower. Maybe you are > > able to help me? > > > > best regards > > -- > > > > * Martin Grimmer * > > Developer, Semantic Web Project, IT > > > > Unister GmbH > > Barfußgässchen 11 | 04109 Leipzig > > > > Telefon: +49 (0)341 49288 5064 > > [email protected] > > <mailto:%0a%20%[email protected]<0a%2520%[email protected]> > > > > www.unister.de <http://www.unister.de> > > > > Vertretungsberechtigter Geschäftsführer: Thomas Wagner > > Amtsgericht Leipzig, HRB: 19056 > > > > _______________________________________________ > > Neo4j mailing list > > [email protected] > > https://lists.neo4j.org/mailman/listinfo/user > > > > _______________________________________________ > > Neo4j mailing list > > [email protected] > > https://lists.neo4j.org/mailman/listinfo/user > > _______________________________________________ > Neo4j mailing list > [email protected] > https://lists.neo4j.org/mailman/listinfo/user > -- Mattias Persson, [[email protected]] Hacker, Neo Technology www.neotechnology.com _______________________________________________ Neo4j mailing list [email protected] https://lists.neo4j.org/mailman/listinfo/user
