Improve RexConnect Performance

inthefabric / RexConnect

Connect to Rexster/RexPro via TCP connection.

www.inthefabric.com

Other

10 stars 0 forks source link

Improve RexConnect Performance #27

Closed zachkinstner closed 11 years ago

zachkinstner commented 11 years ago

Review results of the latest Fabric performance tests. Investigate ways to improve RexConnect performance. Notes from the results:

The "query time" that RexConnect measures is very close to the Gremlin extension timings (usually between 5-7ms). When I measured the JSON parsing + writing to the FilterChain, it was always 0-1ms. Removing the logging output didn't make any noticeable performance difference.

This implies that RexConnect's extra ~5ms is not RexPro's fault. It could be the JSON command processing that RexConnect does, or perhaps the way RexConnect uses Grizzly filters.

zachkinstner commented 11 years ago

The Gremlin extension consistently performs the best. Consider trying to create a RexConnect extension.

Is it possible to create session support within an extension?
This approach also seems cleaner/better than running a separate RexConnectServer (outside of Rexster/Titan's JVM).

zachkinstner commented 11 years ago

Regarding Grizzly filters -- use of StringFilter was just a first attempt, after looking at some example code. Consider these options instead:

zachkinstner commented 11 years ago

Consider trying to create a RexConnect extension.

Done, and it seems to work quite well. Initial tests showed that it performed very close to the Gremlin extension.

Also, the new RexPro serializers may provide a boost -- see #31.

zachkinstner commented 11 years ago

Ideas:

Use the new JSON RexPro serializer, bypassing the MsgPack de/serialization
Cache a pool of RexsterClient instances, avoiding the 1.5ms-2.5ms average instantiation time

zachkinstner commented 11 years ago

Use the new JSON RexPro serializer, bypassing the MsgPack de/serialization

This would only help if RexConnect were not using RexsterClient, since the response is already deserialized by the time it gets back to RexConnect. In any case, the trade-off would be (possibly) less de/serialization time, but (possibly) more transmission times due to larger data flowing between RexPro and the database.

zachkinstner commented 11 years ago

Cache a pool of RexsterClient instances

RexConnect now uses just one static RexsterClient instance. So far, it seems to work fine.

zachkinstner commented 11 years ago

The potential for further optimization seems limited now. The best opportunities I can see are:

Find a faster JSON de/serializer. The one already in use (the "faster" Jackson version) seems to be pretty standard and quite fast. Find a benchmark?
Improve TCP connection speeds. This seems to be the biggest issue. Try Netty?
- Using the Grizzly TCP server, RexConnect gets 3000ms+ response times for almost every test that runs more than 50 iterations.
- Netty seems heavily stream-based. Connecting the incoming stream directly to a JSON deserializer would be optimal.
- Could this also occur (deserializing the response from a stream) on the client side?

zachkinstner commented 11 years ago

Recent testing shows that the 3000ms+ problem was related to the database server (laptop on local network) being connected via wireless. Connecting via ethernet resolved the issue. I have un-done the recent Netty support for now.

zachkinstner commented 11 years ago

Closing this for now. Will move TCP streaming to a separate ticket.