New Release of dbbench Streamlines Database Workload Testing
ddbench is out with a new version! Check out new features, such as the ability to chain jobs and create latency histograms for enhanced analytics.
Join the DZone community and get the full member experience.Join For Free
since we released
, it has been widely adopted across our engineering and sales teams as the definitive tool for testing database workloads. today, we are announcing the availability of a new version of
, as well as a package of high-level tools to enhance it.
in this latest release, we enhanced both the flexibility and ease of use of the tool. we augmented capabilities of
and added a tutorial to help new sales engineers get started. in addition to these enhancements, we released a package of internal tools specifically designed to support high level workflows that use
. these changes improve our technical proof-of-concept (poc) process for our customers and open up
for new workloads and use cases. this version of
not only increases the performance and power of this benchmark testing tool, but also makes it easily accessible to anyone interested in using it.
dbbench in action
one of the new features of
is the ability to display latency histograms during the final analysis to easily detect and understand outliers. in the example below, we can see that most of the queries executed between 0.2 and 0.5 ms, but there were outliers as high as 30ms:
to support more complicated and varying data,
can read arguments from a
file and parameterize queries via the `query-args-file` parameter. the snippet below shows this parameter specified in a configuration.ini file for
[insert] query=insert into table colors (?) query-args-file=/tmp/colors.csv
in addition, the
to chain multiple jobs together, and makes it possible to have external tools in between each of these jobs.
is a package of sales engineering tools, used by the memsql team to easily describe and efficiently run a customer workload during a technical poc. the most important question to answer during a poc is, "how will memsql scale to more concurrent users?"
is one of several tools provided by the
package to help answer this question.
-defined workload at different levels of concurrency to find the limits of the database installation.
for example, i was doing a poc where i wanted to determine how many concurrent inserts a small memsql cluster could handle. i set up a simple
[setup] query=create table test(a varchar(20), b float, c float, d float, \ shard key a (a), key b (b), key c (c), key d (d)) [teardown] query=drop table test [batch sized 128 multi-inserts] query=insert into test values (?, ?, ?, ?), (?, ?, ?, ?), …, (?, ?, ?, ?) query-args-file=/tmp/data.csv concurrency=1
with this configuration to determine that this small test cluster could sustain 100,000 inserts per second in batches of 128, as depicted in the top half of the chart below. in the bottom half of the chart, we see that using more connections allows us to insert more records per second (rps) until we reach 32 connections, after which there is no benefit to using more connections and we see a hugely adverse effect on query latency:
$ dbbench-scaler --database=db --concurrency=1,2,4,8,16,32,64,128,256,512 --output out.png /tmp/test.ini
in this example, not only did
answer the question, "will memsql handle the scale of many users," it also found the ideal number of users for this application.
Published at DZone with permission of Alex Reece, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.