mirror of
https://github.com/nosqlbench/nosqlbench.git
synced 2025-02-25 18:55:28 -06:00
docs and app updates
This commit is contained in:
Jonathan Shook
parent
f9bd9c3564
commit
ae6f636a7a
@ -1,4 +1,4 @@
|
||||
# ebdse -v run type=cql yaml=baselines/cql-iot tags=phase:schema host=dsehost
|
||||
# nb -v run type=cql yaml=baselines/cql-iot tags=phase:schema host=dsehost
|
||||
bindings:
|
||||
machine_id: Mod(<<sources:10000>>); ToHashedUUID() -> java.util.UUID
|
||||
sensor_name: HashedLineToString('data/variable_words.txt')
|
||||
|
||||
@ -1,5 +1,4 @@
|
||||
# nb -v run type=cql yaml=baselines/cql-iot tags=phase:schema
|
||||
host=dsehost
|
||||
# nb -v run type=cql yaml=baselines/cql-iot tags=phase:schema host=dsehost
|
||||
bindings:
|
||||
machine_id: Mod(<<sources:10000>>); ToHashedUUID() -> java.util.UUID
|
||||
sensor_name: HashedLineToString('data/variable_words.txt')
|
||||
|
||||
@ -1,5 +1,4 @@
|
||||
# nb -v run type=cql yaml=baselines/cql-keyvalue tags=phase:schema
|
||||
host=dsehost
|
||||
# nb -v run type=cql yaml=baselines/cql-keyvalue tags=phase:schema host=dsehost
|
||||
bindings:
|
||||
seq_key: Mod(<<keycount:1000000000>>); ToString() -> String
|
||||
seq_value: Hash(); Mod(<<valuecount:1000000000>>); ToString() -> String
|
||||
|
||||
@ -1,4 +1,4 @@
|
||||
# ebdse -v run type=cql yaml=baselines/cql-widerows tags=phase:schema host=dsehost
|
||||
# nb -v run type=cql yaml=baselines/cql-widerows tags=phase:schema host=dsehost
|
||||
bindings:
|
||||
# for ramp-up and verify
|
||||
part_layout: Div(<<partsize:1000000>>); ToString() -> String
|
||||
|
||||
@ -9,7 +9,7 @@ export default {
|
||||
** Headers of the page
|
||||
*/
|
||||
head: {
|
||||
titleTemplate: '%s' + "nosqlbench docs",
|
||||
titleTemplate: '%s' + "NoSQLBench Docs",
|
||||
title: process.env.npm_package_name || '',
|
||||
meta: [
|
||||
{charset: 'utf-8'},
|
||||
|
||||
@ -9,7 +9,7 @@
|
||||
|
||||
<v-app-bar app dark color="secondary" collapse-on-scroll dense >
|
||||
<v-app-bar-nav-icon @click.stop="toggleDrawer"/>
|
||||
<v-toolbar-title>nosqlbench docs</v-toolbar-title>
|
||||
<v-toolbar-title>NoSQLBench Docs</v-toolbar-title>
|
||||
<v-spacer></v-spacer>
|
||||
<v-toolbar-items>
|
||||
</v-toolbar-items>
|
||||
|
||||
@ -8,10 +8,10 @@
|
||||
|
||||
<v-app-bar app dark color="secondary">
|
||||
<v-app-bar-nav-icon color="primary" @click.stop="toggleDrawer"/>
|
||||
<v-toolbar-title>nosqlbench docs</v-toolbar-title>
|
||||
<v-toolbar-title>NoSQLBench Docs</v-toolbar-title>
|
||||
<v-spacer></v-spacer>
|
||||
<v-toolbar-items>
|
||||
<v-btn text href="https://github.com/datastax/nosqlbench-labs/wiki/Submitting-Feedback">SUBMIT FEEDBACK</v-btn>
|
||||
<v-btn text href="https://github.com/nosqlbench/nosqlbench/wiki/Submitting-Feedback">SUBMIT FEEDBACK</v-btn>
|
||||
</v-toolbar-items>
|
||||
</v-app-bar>
|
||||
|
||||
|
||||
@ -1,9 +1,9 @@
|
||||
<!doctype html>
|
||||
<html>
|
||||
<head>
|
||||
<title>guidebooknosqlbench docs</title><meta data-n-head="1" charset="utf-8"><meta data-n-head="1" name="viewport" content="width=device-width,initial-scale=1"><meta data-n-head="1" data-hid="description" name="description" content="Docs App for NoSQLBench"><link data-n-head="1" rel="icon" type="image/x-icon" href="/favicon.ico"><link data-n-head="1" rel="stylesheet" type="text/css" href="https://fonts.googleapis.com/css?family=Roboto:100,300,400,500,700,900&display=swap"><link data-n-head="1" rel="stylesheet" type="text/css" href="https://cdn.jsdelivr.net/npm/@mdi/font@latest/css/materialdesignicons.min.css"><link rel="preload" href="/_nuxt/bbbb289c471766021bc7.js" as="script"><link rel="preload" href="/_nuxt/ba3d87d913919f4a90b7.js" as="script"><link rel="preload" href="/_nuxt/b731eebc22dad37c5c4f.js" as="script"><link rel="preload" href="/_nuxt/4f2a13032e26b25bda78.js" as="script">
|
||||
<title>guidebookNoSQLBench Docs</title><meta data-n-head="1" charset="utf-8"><meta data-n-head="1" name="viewport" content="width=device-width,initial-scale=1"><meta data-n-head="1" data-hid="description" name="description" content="Docs App for NoSQLBench"><link data-n-head="1" rel="icon" type="image/x-icon" href="/favicon.ico"><link data-n-head="1" rel="stylesheet" type="text/css" href="https://fonts.googleapis.com/css?family=Roboto:100,300,400,500,700,900&display=swap"><link data-n-head="1" rel="stylesheet" type="text/css" href="https://cdn.jsdelivr.net/npm/@mdi/font@latest/css/materialdesignicons.min.css"><link rel="preload" href="/_nuxt/53667d09397c029ad15e.js" as="script"><link rel="preload" href="/_nuxt/ba3d87d913919f4a90b7.js" as="script"><link rel="preload" href="/_nuxt/b731eebc22dad37c5c4f.js" as="script"><link rel="preload" href="/_nuxt/7dd5646c91bbd00029e3.js" as="script">
|
||||
</head>
|
||||
<body>
|
||||
<div id="__nuxt"><style>#nuxt-loading{visibility:hidden;opacity:0;position:absolute;left:0;right:0;top:0;bottom:0;display:flex;justify-content:center;align-items:center;flex-direction:column;animation:nuxtLoadingIn 10s ease;-webkit-animation:nuxtLoadingIn 10s ease;animation-fill-mode:forwards;overflow:hidden}@keyframes nuxtLoadingIn{0%{visibility:hidden;opacity:0}20%{visibility:visible;opacity:0}100%{visibility:visible;opacity:1}}@-webkit-keyframes nuxtLoadingIn{0%{visibility:hidden;opacity:0}20%{visibility:visible;opacity:0}100%{visibility:visible;opacity:1}}#nuxt-loading>div,#nuxt-loading>div:after{border-radius:50%;width:5rem;height:5rem}#nuxt-loading>div{font-size:10px;position:relative;text-indent:-9999em;border:.5rem solid #f5f5f5;border-left:.5rem solid #fff;-webkit-transform:translateZ(0);-ms-transform:translateZ(0);transform:translateZ(0);-webkit-animation:nuxtLoading 1.1s infinite linear;animation:nuxtLoading 1.1s infinite linear}#nuxt-loading.error>div{border-left:.5rem solid #ff4500;animation-duration:5s}@-webkit-keyframes nuxtLoading{0%{-webkit-transform:rotate(0);transform:rotate(0)}100%{-webkit-transform:rotate(360deg);transform:rotate(360deg)}}@keyframes nuxtLoading{0%{-webkit-transform:rotate(0);transform:rotate(0)}100%{-webkit-transform:rotate(360deg);transform:rotate(360deg)}}</style><script>window.addEventListener("error",function(){var e=document.getElementById("nuxt-loading");e&&(e.className+=" error")})</script><div id="nuxt-loading" aria-live="polite" role="status"><div>Loading...</div></div></div>
|
||||
<script type="text/javascript" src="/_nuxt/bbbb289c471766021bc7.js"></script><script type="text/javascript" src="/_nuxt/ba3d87d913919f4a90b7.js"></script><script type="text/javascript" src="/_nuxt/b731eebc22dad37c5c4f.js"></script><script type="text/javascript" src="/_nuxt/4f2a13032e26b25bda78.js"></script></body>
|
||||
<script type="text/javascript" src="/_nuxt/53667d09397c029ad15e.js"></script><script type="text/javascript" src="/_nuxt/ba3d87d913919f4a90b7.js"></script><script type="text/javascript" src="/_nuxt/b731eebc22dad37c5c4f.js"></script><script type="text/javascript" src="/_nuxt/7dd5646c91bbd00029e3.js"></script></body>
|
||||
</html>
|
||||
|
||||
@ -1 +1 @@
|
||||
!function(e){function r(data){for(var r,n,f=data[0],l=data[1],d=data[2],i=0,h=[];i<f.length;i++)n=f[i],Object.prototype.hasOwnProperty.call(o,n)&&o[n]&&h.push(o[n][0]),o[n]=0;for(r in l)Object.prototype.hasOwnProperty.call(l,r)&&(e[r]=l[r]);for(v&&v(data);h.length;)h.shift()();return c.push.apply(c,d||[]),t()}function t(){for(var e,i=0;i<c.length;i++){for(var r=c[i],t=!0,n=1;n<r.length;n++){var l=r[n];0!==o[l]&&(t=!1)}t&&(c.splice(i--,1),e=f(f.s=r[0]))}return e}var n={},o={8:0},c=[];function f(r){if(n[r])return n[r].exports;var t=n[r]={i:r,l:!1,exports:{}};return e[r].call(t.exports,t,t.exports,f),t.l=!0,t.exports}f.e=function(e){var r=[],t=o[e];if(0!==t)if(t)r.push(t[2]);else{var n=new Promise((function(r,n){t=o[e]=[r,n]}));r.push(t[2]=n);var c,script=document.createElement("script");script.charset="utf-8",script.timeout=120,f.nc&&script.setAttribute("nonce",f.nc),script.src=function(e){return f.p+""+{0:"55bb9a1be83797eee63f",1:"b8a47e05eded23bac7ed",4:"c28caf599093f6fe5786",5:"09eb2af0af9c15c6d621",6:"428c6c33fdbc344a773a",7:"ecd4a42f2cc80fb75abd"}[e]+".js"}(e);var l=new Error;c=function(r){script.onerror=script.onload=null,clearTimeout(d);var t=o[e];if(0!==t){if(t){var n=r&&("load"===r.type?"missing":r.type),c=r&&r.target&&r.target.src;l.message="Loading chunk "+e+" failed.\n("+n+": "+c+")",l.name="ChunkLoadError",l.type=n,l.request=c,t[1](l)}o[e]=void 0}};var d=setTimeout((function(){c({type:"timeout",target:script})}),12e4);script.onerror=script.onload=c,document.head.appendChild(script)}return Promise.all(r)},f.m=e,f.c=n,f.d=function(e,r,t){f.o(e,r)||Object.defineProperty(e,r,{enumerable:!0,get:t})},f.r=function(e){"undefined"!=typeof Symbol&&Symbol.toStringTag&&Object.defineProperty(e,Symbol.toStringTag,{value:"Module"}),Object.defineProperty(e,"__esModule",{value:!0})},f.t=function(e,r){if(1&r&&(e=f(e)),8&r)return e;if(4&r&&"object"==typeof e&&e&&e.__esModule)return e;var t=Object.create(null);if(f.r(t),Object.defineProperty(t,"default",{enumerable:!0,value:e}),2&r&&"string"!=typeof e)for(var n in e)f.d(t,n,function(r){return e[r]}.bind(null,n));return t},f.n=function(e){var r=e&&e.__esModule?function(){return e.default}:function(){return e};return f.d(r,"a",r),r},f.o=function(object,e){return Object.prototype.hasOwnProperty.call(object,e)},f.p="/_nuxt/",f.oe=function(e){throw console.error(e),e};var l=window.webpackJsonp=window.webpackJsonp||[],d=l.push.bind(l);l.push=r,l=l.slice();for(var i=0;i<l.length;i++)r(l[i]);var v=d;t()}([]);
|
||||
!function(e){function r(data){for(var r,n,f=data[0],l=data[1],d=data[2],i=0,h=[];i<f.length;i++)n=f[i],Object.prototype.hasOwnProperty.call(o,n)&&o[n]&&h.push(o[n][0]),o[n]=0;for(r in l)Object.prototype.hasOwnProperty.call(l,r)&&(e[r]=l[r]);for(v&&v(data);h.length;)h.shift()();return c.push.apply(c,d||[]),t()}function t(){for(var e,i=0;i<c.length;i++){for(var r=c[i],t=!0,n=1;n<r.length;n++){var l=r[n];0!==o[l]&&(t=!1)}t&&(c.splice(i--,1),e=f(f.s=r[0]))}return e}var n={},o={8:0},c=[];function f(r){if(n[r])return n[r].exports;var t=n[r]={i:r,l:!1,exports:{}};return e[r].call(t.exports,t,t.exports,f),t.l=!0,t.exports}f.e=function(e){var r=[],t=o[e];if(0!==t)if(t)r.push(t[2]);else{var n=new Promise((function(r,n){t=o[e]=[r,n]}));r.push(t[2]=n);var c,script=document.createElement("script");script.charset="utf-8",script.timeout=120,f.nc&&script.setAttribute("nonce",f.nc),script.src=function(e){return f.p+""+{0:"55bb9a1be83797eee63f",1:"b8a47e05eded23bac7ed",4:"b3e025f0863187be1b03",5:"d367b2f4f2ccc5cdcc57",6:"428c6c33fdbc344a773a",7:"ecd4a42f2cc80fb75abd"}[e]+".js"}(e);var l=new Error;c=function(r){script.onerror=script.onload=null,clearTimeout(d);var t=o[e];if(0!==t){if(t){var n=r&&("load"===r.type?"missing":r.type),c=r&&r.target&&r.target.src;l.message="Loading chunk "+e+" failed.\n("+n+": "+c+")",l.name="ChunkLoadError",l.type=n,l.request=c,t[1](l)}o[e]=void 0}};var d=setTimeout((function(){c({type:"timeout",target:script})}),12e4);script.onerror=script.onload=c,document.head.appendChild(script)}return Promise.all(r)},f.m=e,f.c=n,f.d=function(e,r,t){f.o(e,r)||Object.defineProperty(e,r,{enumerable:!0,get:t})},f.r=function(e){"undefined"!=typeof Symbol&&Symbol.toStringTag&&Object.defineProperty(e,Symbol.toStringTag,{value:"Module"}),Object.defineProperty(e,"__esModule",{value:!0})},f.t=function(e,r){if(1&r&&(e=f(e)),8&r)return e;if(4&r&&"object"==typeof e&&e&&e.__esModule)return e;var t=Object.create(null);if(f.r(t),Object.defineProperty(t,"default",{enumerable:!0,value:e}),2&r&&"string"!=typeof e)for(var n in e)f.d(t,n,function(r){return e[r]}.bind(null,n));return t},f.n=function(e){var r=e&&e.__esModule?function(){return e.default}:function(){return e};return f.d(r,"a",r),r},f.o=function(object,e){return Object.prototype.hasOwnProperty.call(object,e)},f.p="/_nuxt/",f.oe=function(e){throw console.error(e),e};var l=window.webpackJsonp=window.webpackJsonp||[],d=l.push.bind(l);l.push=r,l=l.slice();for(var i=0;i<l.length;i++)r(l[i]);var v=d;t()}([]);
|
||||
File diff suppressed because one or more lines are too long
File diff suppressed because one or more lines are too long
File diff suppressed because one or more lines are too long
@ -1,9 +1,9 @@
|
||||
<!doctype html>
|
||||
<html>
|
||||
<head>
|
||||
<title>guidebooknosqlbench docs</title><meta data-n-head="1" charset="utf-8"><meta data-n-head="1" name="viewport" content="width=device-width,initial-scale=1"><meta data-n-head="1" data-hid="description" name="description" content="Docs App for NoSQLBench"><link data-n-head="1" rel="icon" type="image/x-icon" href="/favicon.ico"><link data-n-head="1" rel="stylesheet" type="text/css" href="https://fonts.googleapis.com/css?family=Roboto:100,300,400,500,700,900&display=swap"><link data-n-head="1" rel="stylesheet" type="text/css" href="https://cdn.jsdelivr.net/npm/@mdi/font@latest/css/materialdesignicons.min.css"><link rel="preload" href="/_nuxt/bbbb289c471766021bc7.js" as="script"><link rel="preload" href="/_nuxt/ba3d87d913919f4a90b7.js" as="script"><link rel="preload" href="/_nuxt/b731eebc22dad37c5c4f.js" as="script"><link rel="preload" href="/_nuxt/4f2a13032e26b25bda78.js" as="script">
|
||||
<title>guidebookNoSQLBench Docs</title><meta data-n-head="1" charset="utf-8"><meta data-n-head="1" name="viewport" content="width=device-width,initial-scale=1"><meta data-n-head="1" data-hid="description" name="description" content="Docs App for NoSQLBench"><link data-n-head="1" rel="icon" type="image/x-icon" href="/favicon.ico"><link data-n-head="1" rel="stylesheet" type="text/css" href="https://fonts.googleapis.com/css?family=Roboto:100,300,400,500,700,900&display=swap"><link data-n-head="1" rel="stylesheet" type="text/css" href="https://cdn.jsdelivr.net/npm/@mdi/font@latest/css/materialdesignicons.min.css"><link rel="preload" href="/_nuxt/53667d09397c029ad15e.js" as="script"><link rel="preload" href="/_nuxt/ba3d87d913919f4a90b7.js" as="script"><link rel="preload" href="/_nuxt/b731eebc22dad37c5c4f.js" as="script"><link rel="preload" href="/_nuxt/7dd5646c91bbd00029e3.js" as="script">
|
||||
</head>
|
||||
<body>
|
||||
<div id="__nuxt"><style>#nuxt-loading{visibility:hidden;opacity:0;position:absolute;left:0;right:0;top:0;bottom:0;display:flex;justify-content:center;align-items:center;flex-direction:column;animation:nuxtLoadingIn 10s ease;-webkit-animation:nuxtLoadingIn 10s ease;animation-fill-mode:forwards;overflow:hidden}@keyframes nuxtLoadingIn{0%{visibility:hidden;opacity:0}20%{visibility:visible;opacity:0}100%{visibility:visible;opacity:1}}@-webkit-keyframes nuxtLoadingIn{0%{visibility:hidden;opacity:0}20%{visibility:visible;opacity:0}100%{visibility:visible;opacity:1}}#nuxt-loading>div,#nuxt-loading>div:after{border-radius:50%;width:5rem;height:5rem}#nuxt-loading>div{font-size:10px;position:relative;text-indent:-9999em;border:.5rem solid #f5f5f5;border-left:.5rem solid #fff;-webkit-transform:translateZ(0);-ms-transform:translateZ(0);transform:translateZ(0);-webkit-animation:nuxtLoading 1.1s infinite linear;animation:nuxtLoading 1.1s infinite linear}#nuxt-loading.error>div{border-left:.5rem solid #ff4500;animation-duration:5s}@-webkit-keyframes nuxtLoading{0%{-webkit-transform:rotate(0);transform:rotate(0)}100%{-webkit-transform:rotate(360deg);transform:rotate(360deg)}}@keyframes nuxtLoading{0%{-webkit-transform:rotate(0);transform:rotate(0)}100%{-webkit-transform:rotate(360deg);transform:rotate(360deg)}}</style><script>window.addEventListener("error",function(){var e=document.getElementById("nuxt-loading");e&&(e.className+=" error")})</script><div id="nuxt-loading" aria-live="polite" role="status"><div>Loading...</div></div></div>
|
||||
<script type="text/javascript" src="/_nuxt/bbbb289c471766021bc7.js"></script><script type="text/javascript" src="/_nuxt/ba3d87d913919f4a90b7.js"></script><script type="text/javascript" src="/_nuxt/b731eebc22dad37c5c4f.js"></script><script type="text/javascript" src="/_nuxt/4f2a13032e26b25bda78.js"></script></body>
|
||||
<script type="text/javascript" src="/_nuxt/53667d09397c029ad15e.js"></script><script type="text/javascript" src="/_nuxt/ba3d87d913919f4a90b7.js"></script><script type="text/javascript" src="/_nuxt/b731eebc22dad37c5c4f.js"></script><script type="text/javascript" src="/_nuxt/7dd5646c91bbd00029e3.js"></script></body>
|
||||
</html>
|
||||
|
||||
@ -1,5 +1,5 @@
|
||||
---
|
||||
title: Introducing nosqlbench
|
||||
title: Introducing NoSQLBench
|
||||
weight: 10
|
||||
---
|
||||
|
||||
@ -8,21 +8,11 @@ weight: 10
|
||||
Welcome to the documentation for NoSQLBench. This is a power tool that emulates real application workloads.
|
||||
This means that you can fast-track performance, sizing and data model testing without writing your own testing harness.
|
||||
|
||||
NoSQLBench endeavors to be valuable to all users. We do this by making it easy for you, our user, to
|
||||
do just what you need without worrying about the rest. If you need to do something simple, it should
|
||||
be simple to find the right settings and just do it. If you need something more sophisticated, then you
|
||||
should be able to find what you need with a reasonable amount of effort and no surprises.
|
||||
|
||||
Doing this well requires a coordinated effort in how the tools are documented and layered. We're just
|
||||
getting started with the bundled docs that you are reading now. Look for new and expanded content in this
|
||||
guidebook with each major release. We will be adding docs for more advanced users to unlock based on a how-to format.
|
||||
|
||||
|
||||
## What is NoSQLBench?
|
||||
|
||||
NoSQLBench is a serious performance testing tool for the NoSQL ecosystem.
|
||||
It brings together features and capabilities that are not found in any
|
||||
other tool.
|
||||
|
||||
**NoSQLBench brings advanced testing capabilities into one tool that are not found in other testing tools.**
|
||||
|
||||
- You can run common testing workloads directly from the command line. You
|
||||
can start doing this within 5 minutes of reading this.
|
||||
@ -66,4 +56,12 @@ limited to testing only one type of system. It is our wish to build a community
|
||||
of users and practice around this project so that everyone in the NoSQL ecosystem
|
||||
can benefit from common concepts and understanding and reliable patterns of use.
|
||||
|
||||
## Scalable User Experience
|
||||
|
||||
NoSQLBench endeavors to be valuable to all users. We do this by making it easy for you, our user, to
|
||||
do just what you need without worrying about the rest. If you need to do something simple, it should
|
||||
be simple to find the right settings and just do it. If you need something more sophisticated, then you
|
||||
should be able to find what you need with a reasonable amount of effort and no surprises.
|
||||
|
||||
That is the core design principle behind NoSQLBench. We hope you like it.
|
||||
|
||||
|
||||
@ -1,19 +1,19 @@
|
||||
---
|
||||
title: 02 Running
|
||||
title: 01 Commands
|
||||
weight: 2
|
||||
---
|
||||
|
||||
# 2. Running nosqlbench
|
||||
Let's run a simple test against a cluster to establish some basic familiarity with the NoSQLBench.
|
||||
|
||||
Now that we have nosqlbench installed, we will run a simple test against a DSE cluster to establish some basic familiarity with the tool.
|
||||
|
||||
## Create Schema
|
||||
## Create a Schema
|
||||
|
||||
We will start by creating a simple schema in the database.
|
||||
From your command line, go ahead and execute the following command,
|
||||
replacing the `host=<dse-host-or-ip>` with that of one of your database nodes.
|
||||
|
||||
./nb run type=cql yaml=baselines/cql-keyvalue tags=phase:schema host=<dse-host-or-ip>
|
||||
```
|
||||
./nb run type=cql yaml=baselines/cql-keyvalue tags=phase:schema host=<dse-host-or-ip>
|
||||
```
|
||||
|
||||
This command is creating the following schema in your database:
|
||||
|
||||
@ -100,7 +100,7 @@ baselines/cql-keyvalue: 8.87%/Running (details: min=0 cycle=8868 max=100000)
|
||||
baselines/cql-keyvalue: 100.00%/Finished (details: min=0 cycle=100000 max=100000)
|
||||
```
|
||||
|
||||
## Run main workload
|
||||
## Run the main test phase
|
||||
|
||||
Now that we have a base dataset of 100k rows in the database, we will now run a mixed read / write workload, by default this runs a 50% read / 50% write workload.
|
||||
|
||||
@ -1,11 +0,0 @@
|
||||
---
|
||||
title: Your first run
|
||||
weight: 1
|
||||
---
|
||||
|
||||
If you are on Linux, you should be able to start getting useful results immediately with this command:
|
||||
|
||||
|
||||
|
||||
1. `./nb run type=cql yaml=baselines/cql-iot tags=phase:schema`
|
||||
2. `./nb run type=cql yaml=baselines/cql-iot tags=phase:main
|
||||
@ -1,22 +1,24 @@
|
||||
---
|
||||
title: 03 Getting Results
|
||||
title: 02 Results
|
||||
weight: 3
|
||||
---
|
||||
|
||||
# 3. Getting Results
|
||||
|
||||
Coming off of our first run with nosqlbench, we ran a very simple workload against our database. In that example, we saw that nosqlbench writes to a log file and it is in that log file where the most basic form of metrics are displayed.
|
||||
We just ran a very simple workload against our database. In that example, we saw that
|
||||
nosqlbench writes to a log file and it is in that log file where the most basic form of metrics are displayed.
|
||||
|
||||
## Log File Metrics
|
||||
|
||||
For our previous run, we saw that nosqlbench was writing to `logs/scenario_20190812_154431_028.log`
|
||||
|
||||
Even when you don't configure nosqlbench to write its metrics to another location, it will periodically report all the metrics to the log file.
|
||||
At the end of a scenario, before nosqlbench shuts down, it will flush the partial reporting interval again to the logs. This means you can always
|
||||
look in the logs for metrics information.
|
||||
Even when you don't configure nosqlbench to write its metrics to another location, it
|
||||
will periodically report all the metrics to the log file. At the end of a scenario,
|
||||
before nosqlbench shuts down, it will flush the partial reporting interval again to
|
||||
the logs. This means you can always look in the logs for metrics information.
|
||||
|
||||
:::warning
|
||||
If you look in the logs for metrics, be aware that the last report will only contain a partial interval of results. When looking at the last partial window, only metrics which average over time or which compute the mean for the whole test will be meaningful.
|
||||
If you look in the logs for metrics, be aware that the last report will only contain a
|
||||
partial interval of results. When looking at the last partial window, only metrics which
|
||||
average over time or which compute the mean for the whole test will be meaningful.
|
||||
:::
|
||||
|
||||
|
||||
@ -1,17 +1,22 @@
|
||||
---
|
||||
title: 04 Reading Metrics
|
||||
title: 03 Metrics
|
||||
weight: 4
|
||||
---
|
||||
|
||||
# 4. Reading Metrics
|
||||
|
||||
A set of core metrics are provided for every workload that runs with nosqlbench, regardless of the activity type and protocol used. This section explains each of these metrics and shows an example of them from the log file.
|
||||
A set of core metrics are provided for every workload that runs with nosqlbench,
|
||||
regardless of the activity type and protocol used. This section explains each of
|
||||
these metrics and shows an example of them from the log file.
|
||||
|
||||
## metric: result
|
||||
|
||||
This is the primary metric that should be used to get a quick idea of the throughput and latency for a given run. It encapsulates the entire operation life cycle ( ie. bind, execute, get result back ).
|
||||
This is the primary metric that should be used to get a quick idea of the
|
||||
throughput and latency for a given run. It encapsulates the entire
|
||||
operation life cycle ( ie. bind, execute, get result back ).
|
||||
|
||||
For this example we see that we averaged 3732 operations / second with 3.6ms 75th percentile latency and 23.9ms 99th percentile latency. Note the raw metrics are in microseconds. This duration_unit may change depending on how a user configures nosqlbench, so always double-check it.
|
||||
For this example we see that we averaged 3732 operations / second with 3.6ms
|
||||
75th percentile latency and 23.9ms 99th percentile latency. Note the raw metrics are
|
||||
in microseconds. This duration_unit may change depending on how a user configures
|
||||
nosqlbench, so always double-check it.
|
||||
|
||||
```
|
||||
2019-08-12 15:46:01,310 INFO [main] i.e.c.ScenarioResult [Slf4jReporter.java:373] type=TIMER, name=baselines/cql-keyvalue.result, count=100000, min=233.48, max=358596.607, mean=3732.00338612, stddev=10254.850416061185, median=1874.815, p75=3648.767, p95=10115.071, p98=15855.615, p99=23916.543, p999=111292.415, mean_rate=4024.0234405430424, m1=3514.053841156124, m5=3307.431472596865, m15=3268.6786509004132, rate_unit=events/second, duration_unit=microseconds
|
||||
@ -19,9 +24,13 @@ For this example we see that we averaged 3732 operations / second with 3.6ms 75t
|
||||
|
||||
## metric: result-success
|
||||
|
||||
This metric shows whether there were any errors during the run. You can confirm that the count is equal to the number of cycles for the run if you are expecting or requiring zero failed operations.
|
||||
This metric shows whether there were any errors during the run. You can confirm that
|
||||
the count is equal to the number of cycles for the run if
|
||||
you are expecting or requiring zero failed operations.
|
||||
|
||||
Here we see that all 100k of our cycles succeeded. Note that the metrics for throughput and latency here are slightly different than the `results` metric simply because this is a separate timer that only includes operations which completed with no exceptions.
|
||||
Here we see that all 100k of our cycles succeeded. Note that the metrics for throughput
|
||||
and latency here are slightly different than the `results` metric simply because this
|
||||
is a separate timer that only includes operations which completed with no exceptions.
|
||||
|
||||
```
|
||||
2019-08-12 15:46:01,452 INFO [main] i.e.c.ScenarioResult [Slf4jReporter.java:373] type=TIMER, name=baselines/cql-keyvalue.result-success, count=100000, min=435.168, max=358645.759, mean=3752.40990808, stddev=10251.524945886964, median=1889.791, p75=3668.479, p95=10154.495, p98=15884.287, p99=24280.063, p999=111443.967, mean_rate=4003.3090048756894, m1=3523.40328629036, m5=3318.8463896065778, m15=3280.480326762243, rate_unit=events/second, duration_unit=microseconds
|
||||
@ -29,16 +38,19 @@ Here we see that all 100k of our cycles succeeded. Note that the metrics for thr
|
||||
|
||||
## metric: resultset-size
|
||||
|
||||
For read workloads, this metric shows the size of result sent back to nosqlbench from the server. This is useful to confirm that you are reading rows that already exist in the database.
|
||||
For read workloads, this metric shows the size of result sent back to nosqlbench
|
||||
from the server. This is useful to confirm that you are reading rows that already
|
||||
exist in the database.
|
||||
|
||||
TODO: talk about mix of read / writes and how that affects this metric
|
||||
```
|
||||
2019-08-12 15:46:00,298 INFO [main] i.e.c.ScenarioResult [Slf4jReporter.java:373] type=HISTOGRAM, name=baselines/cql-keyvalue.resultset-size, count=100000, min=0, max=1, mean=8.0E-5, stddev=0.008943914131967056, median=0.0, p75=0.0, p95=0.0, p98=0.0, p99=0.0, p999=0.0
|
||||
```
|
||||
|
||||
#### metric: tries
|
||||
|
||||
nosqlbench will retry failures 10 times by default, this is configurable via the `maxtries` command line option < link >. This metric shows a histogram of the number of tries that each operation required, in this example, there were no retries as the `count` is 100k.
|
||||
nosqlbench will retry failures 10 times by default, this is configurable via the `maxtries` command line
|
||||
option for the cql activity type. This metric shows a histogram of the number of tries that each operation
|
||||
required, in this example, there were no retries as the `count` is 100k.
|
||||
```
|
||||
2019-08-12 15:46:00,341 INFO [main] i.e.c.ScenarioResult [Slf4jReporter.java:373] type=HISTOGRAM, name=baselines/cql-keyvalue.tries, count=100000, min=1, max=1, mean=1.0, stddev=0.0, median=1.0, p75=1.0, p95=1.0, p98=1.0, p99=1.0, p999=1.0
|
||||
```
|
||||
@ -59,5 +71,8 @@ To get more information on these options, see the output of
|
||||
|
||||
### Congratulations
|
||||
|
||||
You have completed your first run with nosqlbench! Let's head over to the Next Steps section < link > to talk about the possibilities that are now at our fingertips.
|
||||
You have completed your first run with nosqlbench!
|
||||
|
||||
In the 'Next Steps' section, you'll find options for how to continue, whether you are looking
|
||||
for basic testing or something more advanced.
|
||||
|
||||
@ -0,0 +1,45 @@
|
||||
---
|
||||
title: Next Steps
|
||||
weight: 5
|
||||
---
|
||||
|
||||
Now that you've run nosqlbench for the first time and seen what it does, you can
|
||||
choose what level of customization you want for further testing.
|
||||
|
||||
The sections below describe key areas that users typically customize
|
||||
when working with nosqlbench.
|
||||
|
||||
Everyone who uses nosqlbench will want to get familiar with the 'NoSQLBench Basics' section below.
|
||||
This is essential reading for new and experienced testers alike.
|
||||
|
||||
## High-Level Users
|
||||
|
||||
Several canonical workloads are already baked-in to nosqlbench for immediate use.
|
||||
If you are simply wanting to drive workloads from nosqlbench without building a custom workload,
|
||||
then you'll want to learn about the available workloads and their options.
|
||||
|
||||
Recommended reading for high-level testing workflow:
|
||||
1. 'Built-In Workloads'
|
||||
2. 'nosqlbench Basics'
|
||||
|
||||
## Workload Builders
|
||||
|
||||
If you want to use nosqlbench to build a tailored workload that closely emulates what
|
||||
a specific application would do, then you can build a YAML file that specifies all
|
||||
of the details of an iterative workload. You can specify the access patterns,
|
||||
data distributions, and more.
|
||||
|
||||
The recommended reading for this is:
|
||||
|
||||
1. 'NoSQLBench Basics'
|
||||
2. All of the 'Designing Workloads' section.
|
||||
3. The online examples (find the links in the Designing Workloads section.)
|
||||
|
||||
## Scenario Developers
|
||||
|
||||
The underlying runtime for a scenario in nosqlbench is based on EngineBlock,
|
||||
which means it has all the scripting power that comes with that. For advanced
|
||||
scenario designs, iterative testing models, or analysis methods, you can use
|
||||
ECMAScript to control the scenario from start to finish. This is an advanced
|
||||
feature that is not recommended for first-time users. A guide for scenario
|
||||
developers will be released in increments.
|
||||
@ -1,35 +0,0 @@
|
||||
---
|
||||
title: 05 Next Steps
|
||||
weight: 5
|
||||
---
|
||||
|
||||
# 5. Next Steps
|
||||
|
||||
Now that you've run nosqlbench for the first time and seen what it does, you can choose what level of customization you want for further testing.
|
||||
|
||||
The sections below describe key areas that users typically customize when working with nosqlbench.
|
||||
|
||||
Everyone who uses nosqlbench will want to get familiar with the basics section below. This is essential reading for new and experienced testers alike.
|
||||
|
||||
## High-Level Users
|
||||
|
||||
Several canonical workloads are already baked-in to nosqlbench for immediate use. If you are simply wanting to drive workloads from nosqlbench without building a custom workload, then you'll want to learn about the available workloads and their options.
|
||||
|
||||
Recommended reading for this is:
|
||||
1. 'Built-In Workloads'
|
||||
2. 'nosqlbench Basics'
|
||||
|
||||
## Workload Builders
|
||||
|
||||
If you want to use nosqlbench to build a tailored workload that closely emulates what a specific application would do, then you can build a YAML file that specifies all of the details of an iterative workload. You can specify the access patterns, data distributions, and more.
|
||||
|
||||
The recommended reading for this is:
|
||||
|
||||
1. 'nosqlbench Basics'
|
||||
2. All of the 'Designing Workloads' section.
|
||||
3. The online examples (find the links in the Designing Workloads section.)
|
||||
|
||||
## Scenario Developers
|
||||
|
||||
The underlying runtime for a scenario in nosqlbench is based on EngineBlock,
|
||||
which means it has all the scripting power that comes with that. For advanced scenario designs, iterative testing models, or analysis methods, you can use ECMAScript to control the scenario from start to finish. This is an advanced feature that is not recommended for first-time users. A guide for scenario developers will be released in increments.
|
||||
@ -1,9 +1,20 @@
|
||||
---
|
||||
title: Getting Started
|
||||
title: Quick Start Example
|
||||
weight: 20
|
||||
---
|
||||
|
||||
# Getting Started
|
||||
If you are on Linux, you should be able to start getting useful results immediately with these commands:
|
||||
|
||||
In this Getting Started track, we will walk you through your first test run with nosqlbench and explain the minimal set of information that you will need to get off the ground. We recommend that you go through the steps in this section in order, as each step builds on the last.
|
||||
1. `/nb run type=cql yaml=baselines/cql-iot tags=phase:schema host=dsehost`
|
||||
2. `./nb run type=cql yaml=baselines/cql-iot tags=phase:main host=dsehost cycles=1M threads=auto host=dsehost`
|
||||
|
||||
You can put your own contact points in place of `dsehost`.
|
||||
|
||||
Alternately, if you have docker installed on your Linux system, and you have permissions to use it, you
|
||||
can use `--docker-metrics` to stand up a live metrics dashboard at port 3000.
|
||||
|
||||
This example doesn't go into much detail about what it is doing. It is here to show you how quickly you can
|
||||
start running real workloads without having to learn much about the machinery that makes it happen.
|
||||
|
||||
The rest of this section has a more elaborate example that exposes some of the basic options you may want to
|
||||
adjust for your first serious test.
|
||||
|
||||
@ -1,10 +1,8 @@
|
||||
---
|
||||
title: nosqlbench CLI Options
|
||||
title: NoSQLBench CLI Options
|
||||
weight: 01
|
||||
---
|
||||
|
||||
# nosqlbench CLI Options
|
||||
|
||||
This is the same documentation you get in markdown format with the
|
||||
`nb --help` command.
|
||||
|
||||
@ -29,7 +27,7 @@ named argument to the previous command. The following example
|
||||
is a commandline with a command *start*, and two named arguments
|
||||
to that command.
|
||||
|
||||
./nb start type=diag alias=example
|
||||
./nb start type=diag alias=example
|
||||
|
||||
### Discovery options ###
|
||||
|
||||
@ -160,7 +158,7 @@ When this option is set, engineblock will start graphite, prometheus, and grafan
|
||||
### Console Options ###
|
||||
Increase console logging levels: (Default console logging level is *warning*)
|
||||
|
||||
-v (info)
|
||||
-v (info)
|
||||
-vv (debug)
|
||||
-vvv (trace)
|
||||
|
||||
|
||||
@ -1,5 +1,5 @@
|
||||
---
|
||||
title: nosqlbench Basics
|
||||
title: NoSQLBench Basics
|
||||
weight: 30
|
||||
---
|
||||
|
||||
|
||||
@ -1,28 +0,0 @@
|
||||
---
|
||||
title: Statement Params
|
||||
weight: 15
|
||||
---
|
||||
|
||||
Statement parameters apply to the defined operations for an activity. Statement
|
||||
parameters are always configurable as part of a `params` block in YAML, for
|
||||
activities that use the [Standard YAML](/user-guide/standard_yaml) format.
|
||||
|
||||
In some cases, an [Activity Parameter](/parameters/activity_params) of the same
|
||||
name can be used to establish a default value. In that case, it will be
|
||||
documented here with the parameter description.
|
||||
|
||||
### ratio
|
||||
|
||||
`ratio: <ratio>`
|
||||
|
||||
Determines the frequency of the affected statements in the operational sequence.
|
||||
This means, in effect, the number of times a given statement will be executed
|
||||
within the planned sequence before it starts over at the beginning. When using ratio,
|
||||
it is important to be aware of *how* these statements are sequenced according
|
||||
to the ratio. That is controlled by [seq](/parameters/activity_params#seq).
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Loading…
Reference in New Issue
Block a user