Hi Frank, Author of "the" node-neo4j here.
https://github.com/thingdom/node-neo4j Unfortunately, `npm install node-neo4j` is *not* this driver. It's a different one. "This" node-neo4j is `npm install neo4j`. The version you want is indeed 2.0.0-RC1. https://www.npmjs.com/package/neo4j You'll need to change your code from `new neo4j(...)` to `new neo4j.GraphDatabase(...)`, and from `db.cypherQuery` to `db.cypher`. Full API docs here for now: https://github.com/thingdom/node-neo4j/blob/v2/API_v2.md Now for the behavior you're seeing where a new connection is being made for every query: that's really odd. What version of Node.js are you running? Node 0.10 and up use Keep-Alive by default under load, so you should not see that there: http://nodejs.org/dist/v0.10.36/docs/api/http.html#http_class_http_agent And Node 0.12 and io.js improve this support: https://iojs.org/api/http.html#http_class_http_agent Nonetheless, node-neo4j v2 does let you pass your own custom http.Agent, so you can control the connection pooling yourself if you like. E.g.: var http = require('http'); var db = new neo4j.GraphDatabase({ url: 'http://...', agent: new http.Agent({...}), }); We run node-neo4j v2 on Node 0.10 in production at FiftyThree and are pretty satisfied with the performance under load. (We use a custom agent to isolate its connection pooling, and have its maxSockets currently set to 20 per Node process.) But perhaps you're exercising something different that we're not aware of. Hope this helps though. Cheers, Aseem On Monday, June 8, 2015 at 3:12:02 AM UTC-4, Frank Celler wrote: > > I changed the index to a constraint and updated the page-cache. > > However, I'm still struggling with the node.js driver. I've tried the > "node-neo4j", which you get in version 2.0.3 using "npm install > node-neo4j". I've created the database link using > > var db = new neo4j('http://neo4j:abc@' + host + ':7474'); > > but when running a lot of db.cypherQuery, I ended up with a lot of > connections in TIME_WAIT: > > $ netstat -anpt | fgrep TIME_WAIT | wc > 1014 7098 98358 > > So, it seems that connections are not keep open. Is there a way to specify > this? For example, the MongoDB driver has a 'poolSize' argument, to specify > how many connections should be keep open. > > Thanks for your help > Frank > > Am Sonntag, 7. Juni 2015 14:25:34 UTC+2 schrieb Michael Hunger: >> >> Hi, >> >> It would have been very nice to be contacted before such an article went >> out and not called out as part of the post to "defend yourself". Just >> saying. >> >> Seraph uses old and outdated, 2-year old APIs (/db/data/cypher and >> /db/data/node) which are not performant >> and also misses relevant headers (e.g. X-Stream:true) for those. >> It also doesn't support http keep-alive. >> >> I would either use requests directly or perhaps node-neo4j 2.x, would >> have to test though. >> >> Configuration for Neo4j also easy to improve, for your store 2.5G >> page-cache memory should be enough. >> The warmup is also not sufficient. >> >> And running the queries once, i.e. cold caches are also a non-production >> approach. >> >> I'm currently looking into it and will post an blog post with my >> recommendations next week. >> >> As we all know benchmark tests are always well suited to the publisher :) >> >> The index should be a unique constraint instead. >> >> Cheers, Michael >> >> Am 07.06.2015 um 12:33 schrieb Frank Celler <[email protected]>: >> >> Hi Christophe, >> >> I'm Frank from ArangoDB. The author of the article, Claudius, is my >> colleague - he currently not at his computer. Therefore, I try to answer >> your questions. Please let me know, if you need more information. Any help >> with the queries is more than welcome. If we can improve them in any way, >> please let us know. >> >> - we raised the ulimit as requested by neo4j when it started: open files >> (-n) 40000 >> >> - there is one index on PROFILES: >> >> neo4j-sh (?)$ schema >> Indexes >> ON :PROFILES(_key) ONLINE >> >> - as far as we understood, there is no need to create an index for edges >> >> - we used "seraph" as node.js driver, because that was recommend in the >> node user group >> >> - we set >> >> dbms.pagecache.memory=20g >> >> (we were told in talk, that this is nowadays the only cache parameter >> that matters). >> >> - we started with >> >> ./bin/neo4j start >> >> - JVM is >> >> java version "1.7.0_79" >> Java(TM) SE Runtime Environment (build 1.7.0_79-b15) >> Java HotSpot(TM) 64-Bit Server VM (build 24.79-b02, mixed mode) >> >> Thanks for your help >> Frank >> >> Am Freitag, 5. Juni 2015 19:25:09 UTC+2 schrieb Christophe Willemsen: >>> >>> I have looked at their repository too. Most of the queries seems >>> 'almost' correct, but there is no information concerning the real schema >>> indexes, the configuration of the JVM etc.., also the results are the >>> throughput so I wait for someone maybe more experimented in these kind of >>> benchmarks in order to reply to it. >>> >>> Le vendredi 5 juin 2015 04:32:59 UTC+2, Michael Hunger a écrit : >>>> >>>> I'm currently on the road but there are several things wrong with it. >>>> Will look into more detail in the next few days >>>> >>>> Michael >>>> >>>> Von meinem iPhone gesendet >>>> >>>> Am 04.06.2015 um 12:57 schrieb Andrii Stesin <[email protected]>: >>>> >>>> Just ran into the following article (published supposedly today Jun 04, >>>> 2015) which claims to contain comparison of benchmark results: Native >>>> multi-model can compete with pure document and graph databases >>>> <https://www.arangodb.com/2015/06/multi-model-benchmark/> which makes >>>> me think that there is something wrong with either their data model or >>>> with >>>> test setup, because results for Neo4j are surprisingly low. >>>> >>>> Am I the only one out there who feel the same? >>>> >>>> WBR, >>>> Andrii >>>> >>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "Neo4j" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to [email protected]. >>>> For more options, visit https://groups.google.com/d/optout. >>>> >>>> >> -- >> You received this message because you are subscribed to the Google Groups >> "Neo4j" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> For more options, visit https://groups.google.com/d/optout. >> >> >> -- You received this message because you are subscribed to the Google Groups "Neo4j" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
