[
https://issues.apache.org/jira/browse/KUDU-1235?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15249461#comment-15249461
]
Todd Lipcon commented on KUDU-1235:
-----------------------------------
A couple things I noticed:
- seems to be reactor-bound on my machine I tried it on with more cores.
Switching the client to create a KuduClient per Getter helped spread the load
across more reactors.
- I found the hash function which assigned connections to reactors on the
server wasn't very good. Switched it out and seems to be spreading more evenly,
but perhaps we should just assign based on load instead.
- was able to do some micro-optimization on the PlainBlockDecoder
implementation. But, I think we should consider a 'v2' for this block format -
the current one is not good for random access since we decode the whole
'offsets' array even if we're just looking for a single value.
-- to help with this issue, I tried changing the block size to 4KB for this
column instead of the default, but it didn't seem to make a difference. Need to
investigate if this is actually propagating down correctly.
- the test was using ASSERTs from the test threads, which contend on appending
to a test-global array. this can also cause crashes. I changed them to CHECKs.
On my 24-core machine (48 hyperthreads) using 32 client threads, with the
changes I'm able to get about 160K gets/second. But, the machine is still 57%
idle. So, it might need more reactors in order to max it out. Optimizing the
reactor a bit may also help.
> Add Get API
> -----------
>
> Key: KUDU-1235
> URL: https://issues.apache.org/jira/browse/KUDU-1235
> Project: Kudu
> Issue Type: New Feature
> Reporter: Binglin Chang
> Assignee: Binglin Chang
> Attachments: perf-get.svg, perf-scan-opt.svg, perf-scan.svg
>
>
> Get API is more user friendly and efficient if use just want primary key
> lookup.
> I setup a cluster and test get/scan single row using ycsb, initial test shows
> better performance for get.
> {noformat}
> kudu_workload:
> recordcount=1000000
> operationcount=1000000
> workload=com.yahoo.ycsb.workloads.CoreWorkload
> readallfields=false
> readproportion=1
> updateproportion=0
> scanproportion=0
> insertproportion=0
> requestdistribution=uniform
> use_get_api=false
> load:
> ./bin/ycsb load kudu -P workloads/kudu_workload -p sync_ops=false -p
> pre_split_num_tablets=1 -p table_name=ycsb_wiki_example -p
> masterQuorum='c3-kudu-tst-st01.bj:32600' -threads 100
> read test:
> ./bin/ycsb run kudu -P workloads/kudu_workload -p
> masterQuorum='c3-kudu-tst-st01.bj:32600' -threads 100
> {noformat}
> Get API:
> [OVERALL], RunTime(ms), 21304.0
> [OVERALL], Throughput(ops/sec), 46939.54187007135
> [CLEANUP], Operations, 100.0
> [CLEANUP], AverageLatency(us), 423.57
> [CLEANUP], MinLatency(us), 24.0
> [CLEANUP], MaxLatency(us), 19327.0
> [CLEANUP], 95thPercentileLatency(us), 52.0
> [CLEANUP], 99thPercentileLatency(us), 18815.0
> [READ], Operations, 1000000.0
> [READ], AverageLatency(us), 2065.185152
> [READ], MinLatency(us), 134.0
> [READ], MaxLatency(us), 92159.0
> [READ], 95thPercentileLatency(us), 2391.0
> [READ], 99thPercentileLatency(us), 6359.0
> [READ], Return=0, 1000000
> Scan API:
> [OVERALL], RunTime(ms), 38259.0
> [OVERALL], Throughput(ops/sec), 26137.6408165399
> [CLEANUP], Operations, 100.0
> [CLEANUP], AverageLatency(us), 47.32
> [CLEANUP], MinLatency(us), 16.0
> [CLEANUP], MaxLatency(us), 1837.0
> [CLEANUP], 95thPercentileLatency(us), 41.0
> [CLEANUP], 99thPercentileLatency(us), 158.0
> [READ], Operations, 1000000.0
> [READ], AverageLatency(us), 3595.825249
> [READ], MinLatency(us), 139.0
> [READ], MaxLatency(us), 3139583.0
> [READ], 95thPercentileLatency(us), 3775.0
> [READ], 99thPercentileLatency(us), 7659.0
> [READ], Return=0, 1000000
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
