Bug 1026352 - C++ vs Java HotRod client performance
C++ vs Java HotRod client performance
Status: VERIFIED
Product: JBoss Data Grid 6
Classification: JBoss
Component: CPP Client (Show other bugs)
6.2.0
Unspecified Unspecified
unspecified Severity medium
: CR2
: 6.2.0
Assigned To: Tristan Tarrant
Alan Field
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-11-04 08:45 EST by Radim Vansa
Modified: 2018-01-29 20:43 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
JBoss Issue Tracker HRCPP-104 Major Resolved MurmurHash3 is not implemented as in Java 2017-12-15 06:39 EST

  None (edit)
Description Radim Vansa 2013-11-04 08:45:08 EST
This bug should track the performance issues for C++ HotRod client.

By preliminary testing we've found that in a test where several hundred clients fire requests to the servers the performance of C++ client is 60% lower than Java client.

Setup:
* 4 cluster nodes, 3 driver nodes
* PUT/GET with 1:2 ratio, 1024 byte entry size
* *NO* delay between requests
* The throughput for > 200 clients (total amount for all nodes) is roughly constant

Results for 6.2.0.ER3.2:
* C++ client: 48k ops/s
* Java client: 120k ops/s
Comment 3 Tristan Tarrant 2013-11-04 15:56:25 EST
Although I don't believe this can change much, for performance we should compile with the Release profile (ER3.2 is compiled with the Debug profile):

cmake -DHOTROD_JBOSS_HOME=/path/to/jdg-server -DCMAKE_BUILD_TYPE=Release ../path/to/source
Comment 4 Radim Vansa 2014-03-27 05:12:20 EDT
After fixing the bugs in MurmurHash implementation (HRCPP-104) the performance has increased to > 120k ops/s for C++ implementation. Best results for recent Java implementation are 140k ops/s.
These results are acceptable.
Further performance change can be expected when asynchronous operations are implemented.

Note You need to log in before you can comment on or make changes to this bug.