Janusgraph: Slow request through gremlin server but not through gremlin local console

[graphdb2]

Hello,

I experience a slow request through gremlin server but it has good performance in gremlin local console

Gremlin server : around 13 sec
Gremlin local console : 1 sec

The client is gremlin.net and janus version is 0.2.0 and 0.3.0 snapshot

I tested both graphson v2 and v3 it did not make any difference.

g.V().has('identifiant', 'rdf/reference.legalentity/public/rdx/VO32SGB').outE('parentof').has('from',lte(1474894850)).and(or(__.has('to',gt(1474894850)),__.hasNot('to'))).inV().outE('state').has('from',lte(1474894850)).and(or(__.has('to',gt(1474894850)),__.hasNot('to'))).inV().as('cState').valueMap('name', 'type','status','country','cityid','keys')

The request return 10k row.

The same request on Neo4j using gremlin server as well run around 1 sec on gremlin.net graphson v3

[FlorianHockmann]

How exactly did you connect from the console? Did you use :remote connect or did you connect directly to your backend?

[graphdb2]

The console is connected directly to the hbase backend.

[graphdb2]

This is the profile of the slow query on the gremlin remote, I have executed the same request several time, so it looks it take 8 sec to serialize 6000 rows with GraphSONMessageSerializerGremlinV2d0.

[graphdb2]

I managed to improve the slow request(3.5 sec) through gremlin server Gson v3 by removing the valueMap and replace by local(properties().group().by(key).by(value)):
gremlin> :> g.V().has('identifiant', 'rdf/reference.legalentity/public/rdx/VO32SGB').outE('parentof').has('from',lte(1474894850)).and(or(__.has('to',gt(1474894850)),__.hasNot('to'))).inV().barrier().outE('state').has('from',lte(1474894850)).and(or(__.has('to',gt(1474894850)),__.hasNot('to'))).inV().as('cState').local(properties().group().by(key).by(value))

It looks it is an old issue : http://mail-archives.apache.org/mod_mbox/tinkerpop-dev/201509.mbox/%[email protected]%3E

[graphdb2]

I found the setup that was causing slow response time on the gremlin server, it was down to this attribute

storage.batch-loading=true

I removed it and the query went down from 3.5 sec to 1 sec.

[pluradj]

Glad you resolved it. Closing.