[
https://issues.apache.org/jira/browse/KUDU-749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16855686#comment-16855686
]
ZhangYao commented on KUDU-749:
-------------------------------
Hi, Todd, :) According to your advice I have implemented "seek before" function
and
make YCSB to get result. I think the improvment is considerable and later I
will
push my code.
YCSB workloada(A zipfian 50/50 update/read workload) with recordcount: 1000000
and operationcount: 10000000
Before change:
UPDATE Operations: 5001052
AverageLatency(us): 3.790199142100502
MinLatency(us): 1
MaxLatency(us): 88703
95thPercentileLatency(us): 7
99thPercentileLatency(us):12
After change:
UPDATE Operations: 5001749
AverageLatency(us): 229.49272324540877
MinLatency(us): 1
MaxLatency(us): 1796095
95thPercentileLatency(us): 7
99thPercentileLatency(us):14
> Improve performance for zipfian update
> --------------------------------------
>
> Key: KUDU-749
> URL: https://issues.apache.org/jira/browse/KUDU-749
> Project: Kudu
> Issue Type: Improvement
> Components: perf, tablet
> Affects Versions: Private Beta
> Reporter: Todd Lipcon
> Priority: Major
> Attachments: screenshot-1.png, screenshot-2.png
>
>
> A zipfian 50/50 update/read workload on YCSB gets slower and slower until
> it's pretty intolerable (random reads taking 100+ms of CPU). It seems like
> all the CPU is spent in DMSIterator::PrepareBatch. We're probably doing
> something dumb here - let's look for some low hanging fruit to fix this.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
