Skip to content
GitLab
Explore
Sign in
Primary navigation
Search or go to…
Project
Y
YCSB
Manage
Activity
Members
Labels
Plan
Issues
0
Issue boards
Milestones
Wiki
Code
Merge requests
0
Repository
Branches
Commits
Tags
Repository graph
Compare revisions
Snippets
Build
Pipelines
Jobs
Pipeline schedules
Artifacts
Deploy
Releases
Model registry
Operate
Environments
Monitor
Incidents
Analyze
Value stream analytics
Contributor analytics
CI/CD analytics
Repository analytics
Model experiments
Help
Help
Support
GitLab documentation
Compare GitLab plans
Community forum
Contribute to GitLab
Provide feedback
Keyboard shortcuts
?
Snippets
Groups
Projects
Show more breadcrumbs
Adnan Ahmad
YCSB
Commits
6f49fd96
Commit
6f49fd96
authored
10 years ago
by
nitsanw
Committed by
Sean Busbey
9 years ago
Browse files
Options
Downloads
Patches
Plain Diff
[core] Read me on CO in the context of YCSB
parent
a152063a
No related branches found
Branches containing commit
No related tags found
No related merge requests found
Changes
1
Hide whitespace changes
Inline
Side-by-side
Showing
1 changed file
core/COORDINATED-OMISSION.md
+27
-0
27 additions, 0 deletions
core/COORDINATED-OMISSION.md
with
27 additions
and
0 deletions
core/COORDINATED-OMISSION.md
0 → 100644
+
27
−
0
View file @
6f49fd96
YCSB in it's original form suffers from Coordinated Omission[1]:
*
Load is controlled by response time
*
Measurement does not account for missing time
*
Measurement starts at beginning of request rather than at intended beginning
To provide a minimal correction patch I propose:
1.
Replace internal histogram implementation with HdrHistogram:
HdrHistogram offers a dynamic range of measurement at a given precision and will
improve the fidelity of reporting. It allows capturing a much wider range of latencies.
We could add controls for corrected/uncorrected measurement. This is appropriate for a
uniform load test, but not for other loads. The mixing of different Ops also makes
this correction unreliable. This could work for a global histogram.
2.
Track intended operation start and report latencies from that point in time:
This will require the introduction of a new measurement point and will inevitably
include measuring some of the internal preparation steps of the load generator.
These overhead should be negligible in the context of a network hop, but could
be corrected for by estimating the load-generator overheads (e.g. by measuring a
no-op DB).
Further correction suggestions:
1.
Correction load control: currently after a pause the load generator will do
operations back to back to catchup, this leads to a flat out throughput mode
of testing as opposed to controlled load.
2.
Move to async model: Scenarios where Ops have no dependency could delegate the
Op execution to a threadpool and thus separate the request rate control from the
synchronous execution of Ops. Measurement would start on queuing for execution.
1.
https://groups.google.com/forum/#!msg/mechanical-sympathy/icNZJejUHfE/BfDekfBEs_sJ
\ No newline at end of file
This diff is collapsed.
Click to expand it.
Preview
0%
Loading
Try again
or
attach a new file
.
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Save comment
Cancel
Please
register
or
sign in
to comment