mirror of
https://github.com/nosqlbench/nosqlbench.git
synced 2025-02-25 18:55:28 -06:00
Merge branch 'master' of https://github.com/nosqlbench/nosqlbench
This commit is contained in:
Jonathan Shook
commit
4a67cc13f2
@ -79,6 +79,11 @@ public class CQLSessionCache implements Shutdownable {
|
||||
String[] contactPoints = activityDef.getParams().getOptionalString("host")
|
||||
.map(h -> h.split(",")).orElse(null);
|
||||
|
||||
if (contactPoints == null) {
|
||||
contactPoints = activityDef.getParams().getOptionalString("hosts")
|
||||
.map(h -> h.split(",")).orElse(null);
|
||||
}
|
||||
|
||||
if (contactPoints != null) {
|
||||
builder.addContactPoints(contactPoints);
|
||||
}else if (scb.isEmpty()){
|
||||
|
||||
@ -1,9 +1,9 @@
|
||||
<!doctype html>
|
||||
<html>
|
||||
<head>
|
||||
<title>guidebookNoSqlBench Guidebook</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/4cea5966dac98b0ba746.js" as="script"><link rel="preload" href="/_nuxt/4624bfb5c053c019954b.js" as="script"><link rel="preload" href="/_nuxt/54674d21809810cadfcb.js" as="script"><link rel="preload" href="/_nuxt/9add61b10767494b3691.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/856e5d85bfbcfcf786ae.js" as="script"><link rel="preload" href="/_nuxt/4624bfb5c053c019954b.js" as="script"><link rel="preload" href="/_nuxt/54674d21809810cadfcb.js" as="script"><link rel="preload" href="/_nuxt/5f1fda305296fff2eb15.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/4cea5966dac98b0ba746.js"></script><script type="text/javascript" src="/_nuxt/4624bfb5c053c019954b.js"></script><script type="text/javascript" src="/_nuxt/54674d21809810cadfcb.js"></script><script type="text/javascript" src="/_nuxt/9add61b10767494b3691.js"></script></body>
|
||||
<script type="text/javascript" src="/_nuxt/856e5d85bfbcfcf786ae.js"></script><script type="text/javascript" src="/_nuxt/4624bfb5c053c019954b.js"></script><script type="text/javascript" src="/_nuxt/54674d21809810cadfcb.js"></script><script type="text/javascript" src="/_nuxt/5f1fda305296fff2eb15.js"></script></body>
|
||||
</html>
|
||||
|
||||
File diff suppressed because one or more lines are too long
@ -1 +0,0 @@
|
||||
!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:"efdb07324aea334c9e80",1:"e0a04b7263a86d58d3ba",4:"7cd152161870ad867e83",5:"d3314fbbc4bf2910b26a",6:"ba88ffaeb47c59c7387b",7:"58b1f97573b39e9daf48"}[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
@ -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:"efdb07324aea334c9e80",1:"e0a04b7263a86d58d3ba",4:"7cd152161870ad867e83",5:"d3314fbbc4bf2910b26a",6:"ba88ffaeb47c59c7387b",7:"2b06a447c63ab9b99324"}[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:"efdb07324aea334c9e80",1:"e0a04b7263a86d58d3ba",4:"b1f17d3a199a3eda0e71",5:"e4bdf51517af19e13e1f",6:"ba88ffaeb47c59c7387b",7:"2b06a447c63ab9b99324"}[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()}([]);
|
||||
@ -1 +0,0 @@
|
||||
!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:"efdb07324aea334c9e80",1:"e0a04b7263a86d58d3ba",4:"7cd152161870ad867e83",5:"d3314fbbc4bf2910b26a",6:"ba88ffaeb47c59c7387b",7:"0c2e6386e973ddff2f93"}[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 Guidebook</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/4cea5966dac98b0ba746.js" as="script"><link rel="preload" href="/_nuxt/4624bfb5c053c019954b.js" as="script"><link rel="preload" href="/_nuxt/54674d21809810cadfcb.js" as="script"><link rel="preload" href="/_nuxt/9add61b10767494b3691.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/856e5d85bfbcfcf786ae.js" as="script"><link rel="preload" href="/_nuxt/4624bfb5c053c019954b.js" as="script"><link rel="preload" href="/_nuxt/54674d21809810cadfcb.js" as="script"><link rel="preload" href="/_nuxt/5f1fda305296fff2eb15.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/4cea5966dac98b0ba746.js"></script><script type="text/javascript" src="/_nuxt/4624bfb5c053c019954b.js"></script><script type="text/javascript" src="/_nuxt/54674d21809810cadfcb.js"></script><script type="text/javascript" src="/_nuxt/9add61b10767494b3691.js"></script></body>
|
||||
<script type="text/javascript" src="/_nuxt/856e5d85bfbcfcf786ae.js"></script><script type="text/javascript" src="/_nuxt/4624bfb5c053c019954b.js"></script><script type="text/javascript" src="/_nuxt/54674d21809810cadfcb.js"></script><script type="text/javascript" src="/_nuxt/5f1fda305296fff2eb15.js"></script></body>
|
||||
</html>
|
||||
|
||||
@ -1,14 +1,3 @@
|
||||
virtdata-dev/concepts.md
|
||||
virtdata-funcref/funcref_premade.md
|
||||
virtdata-funcref/funcref_functional.md
|
||||
virtdata-funcref/funcref_diagnostics.md
|
||||
virtdata-funcref/funcref_state.md
|
||||
virtdata-funcref/funcref_nulls.md
|
||||
virtdata-funcref/funcref_datetime.md
|
||||
virtdata-funcref/funcref_conversion.md
|
||||
virtdata-funcref/funcref_collections.md
|
||||
virtdata-funcref/funcref_distributions.md
|
||||
virtdata-funcref/funcref_general.md
|
||||
05_activitytypes/06_cql_at.md
|
||||
05_activitytypes/06_stdout_at.md
|
||||
05_activitytypes/index.md
|
||||
@ -16,11 +5,6 @@ virtdata-funcref/funcref_general.md
|
||||
04_builtins/index.md
|
||||
04_builtins/cql-keyvalue.md
|
||||
04_builtins/cql-widerows.md
|
||||
01_dsbench/02_compatibility.md
|
||||
01_dsbench/05_troubleshooting.md
|
||||
01_dsbench/03_release_notes.md
|
||||
01_dsbench/index.md
|
||||
01_dsbench/04_support_options.md
|
||||
09_reference/06_advanced_metrics.md
|
||||
09_reference/05_timing_terms.md
|
||||
09_reference/index.md
|
||||
@ -46,6 +30,11 @@ virtdata-funcref/funcref_general.md
|
||||
03_basics/index.md
|
||||
03_basics/02_grafana_metrics.md
|
||||
03_basics/01_command_line.md
|
||||
01_nosqlbench/02_compatibility.md
|
||||
01_nosqlbench/05_troubleshooting.md
|
||||
01_nosqlbench/03_release_notes.md
|
||||
01_nosqlbench/index.md
|
||||
01_nosqlbench/04_support_options.md
|
||||
02_getting_started/03_getting_results.md
|
||||
02_getting_started/05_next_steps.md
|
||||
02_getting_started/04_reading_metrics.md
|
||||
|
||||
|
@ -1,25 +0,0 @@
|
||||
---
|
||||
title: Compatibility
|
||||
weight: 3
|
||||
---
|
||||
|
||||
# Binary Format
|
||||
|
||||
DSBench is distributed primarily as a binary for Linux distributions. The DSBench binary includes its own OpenJDK runtime. It should work for most modern Linux distributions. The only requirement is that fuse be installed (it is usually already present) on the client system.
|
||||
|
||||
# Supported Systems
|
||||
|
||||
DSBench runs on Linux as a binary distribution. Any modern Linux which can run AppImage binaries should work.
|
||||
|
||||
# Activity Types
|
||||
|
||||
In nosqlbench terms, this means:
|
||||
|
||||
Activity types are how DSBench gets its support for different protocols or client drivers. The initial release of DSBench includes support for
|
||||
these activity types:
|
||||
|
||||
- The CQL activity type
|
||||
- The initial release of the CQL activity type uses the DataStax driver version 1.9.0
|
||||
- The stdout activity type.
|
||||
|
||||
|
||||
@ -1,16 +0,0 @@
|
||||
---
|
||||
title: Introducing DSBench
|
||||
weight: 10
|
||||
---
|
||||
|
||||
# DataStax Bench Documentation
|
||||
|
||||
Welcome to the documentation for DataStax Bench (DSBench). DSBench 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.
|
||||
|
||||
DSBench 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 release. We will be adding docs for more advanced users to unlock based on a how-to format.
|
||||
|
||||
We take requests! If you have specific nosqlbench topics you'd like to
|
||||
have added to this guidebook, please make a request as described under the Support Options section.
|
||||
@ -0,0 +1,25 @@
|
||||
---
|
||||
title: Compatibility
|
||||
weight: 3
|
||||
---
|
||||
|
||||
# Binary Format
|
||||
|
||||
nosqlbench is distributed primarily as a binary for Linux distributions. The nosqlbench binary includes its own OpenJDK runtime. It should work for most modern Linux distributions. The only requirement is that fuse be installed (it is usually already present) on the client system.
|
||||
|
||||
# Supported Systems
|
||||
|
||||
nosqlbench runs on Linux as a binary distribution. Any modern Linux which can run AppImage binaries should work.
|
||||
|
||||
# Activity Types
|
||||
|
||||
In nosqlbench terms, this means:
|
||||
|
||||
Activity types are how nosqlbench gets its support for different protocols or client drivers. The initial release of nosqlbench includes support for
|
||||
these activity types:
|
||||
|
||||
- The CQL activity type
|
||||
- The initial release of the CQL activity type uses the DataStax driver version 1.9.0
|
||||
- The stdout activity type.
|
||||
|
||||
|
||||
@ -9,15 +9,15 @@ These guidelines are mirrored at the [Submitting Feedback](https://github.com/da
|
||||
|
||||
## Community Support
|
||||
|
||||
It is supported by a community of active users at [DataStax DSBench Community](https://community.datastax.com/spaces/51/index.html).
|
||||
It is supported by a community of active users at [DataStax nosqlbench Community](https://community.datastax.com/spaces/51/index.html).
|
||||
|
||||
## Bug Fixes
|
||||
|
||||
If you think you have found a bug, please [file a bug report](https://github.com/datastax/nosqlbench-labs/issues/new?labels=bug). DSBench is actively used within DataStax, and verified bugs will get attention as resources permit. Bugs reports which are more detailed, or bug reports which include steps to reproduce will get attention first.
|
||||
If you think you have found a bug, please [file a bug report](https://github.com/datastax/nosqlbench-labs/issues/new?labels=bug). nosqlbench is actively used within DataStax, and verified bugs will get attention as resources permit. Bugs reports which are more detailed, or bug reports which include steps to reproduce will get attention first.
|
||||
|
||||
## Feature Requests
|
||||
|
||||
If you would like to see something in DSBench that is not there yet,
|
||||
If you would like to see something in nosqlbench that is not there yet,
|
||||
please [submit a feature request](https://github.com/datastax/nosqlbench-labs/issues/new?labels=feature).
|
||||
|
||||
## Documentation Requests
|
||||
@ -10,7 +10,7 @@ common issue as we uncover them.
|
||||
|
||||
## Errors while starting nosqlbench binary
|
||||
|
||||
If you get an error while trying to run the Linux DSBench binary, ensure that you have the system module installed for fuse. This module is used by the AppImage runtime that allows for a bundled binary.
|
||||
If you get an error while trying to run the Linux nosqlbench binary, ensure that you have the system module installed for fuse. This module is used by the AppImage runtime that allows for a bundled binary.
|
||||
|
||||
## Errors when running java -jar
|
||||
|
||||
16
docs/services/docs/markdown/01_nosqlbench/index.md
Normal file
16
docs/services/docs/markdown/01_nosqlbench/index.md
Normal file
@ -0,0 +1,16 @@
|
||||
---
|
||||
title: Introducing nosqlbench
|
||||
weight: 10
|
||||
---
|
||||
|
||||
# nosqlbench docs
|
||||
|
||||
Welcome to the documentation for nosqlbench. nosqlbench 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 release. We will be adding docs for more advanced users to unlock based on a how-to format.
|
||||
|
||||
We take requests! If you have specific nosqlbench topics you'd like to
|
||||
have added to this guidebook, please make a request as described under the Support Options section.
|
||||
@ -3,7 +3,7 @@ title: 01 Installing
|
||||
weight: 1
|
||||
---
|
||||
|
||||
# 1. Installing DSBench
|
||||
# 1. Installing nosqlbench
|
||||
|
||||
If you are viewing this via the guidebook, you've already completed this step and you can move on to the next section.
|
||||
|
||||
|
||||
@ -3,9 +3,9 @@ title: 02 Running
|
||||
weight: 2
|
||||
---
|
||||
|
||||
# 2. Running DSBench
|
||||
# 2. Running nosqlbench
|
||||
|
||||
Now that we have DSBench installed, we will run a simple test against a DSE cluster to establish some basic familiarity with the tool.
|
||||
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
|
||||
|
||||
@ -28,20 +28,20 @@ CREATE TABLE baselines.keyvalue (
|
||||
|
||||
Let's break down each of those command line options.
|
||||
|
||||
`start` tells DSBench to start an activity.
|
||||
`start` tells nosqlbench to start an activity.
|
||||
|
||||
`type=...` is used to specify the activity type. In this case we are using `cql`, which tells DSBench to use the DataStax Java Driver and execute CQL statements against a database.
|
||||
`type=...` is used to specify the activity type. In this case we are using `cql`, which tells nosqlbench to use the DataStax Java Driver and execute CQL statements against a database.
|
||||
|
||||
`yaml=...` is used to specify the yaml file that defines the activity.
|
||||
All activities require a yaml in which you configure things such as data bindings and CQL statements, but don't worry about those details right now.
|
||||
|
||||
In this example, we use `baselines/cql-keyvalue` which is a pre-built workload that is packaged with DSBench.
|
||||
In this example, we use `baselines/cql-keyvalue` which is a pre-built workload that is packaged with nosqlbench.
|
||||
|
||||
`tags=phase:schema` tells DSBench to run the yaml block that has the `phase:schema` defined as one of its tags.
|
||||
`tags=phase:schema` tells nosqlbench to run the yaml block that has the `phase:schema` defined as one of its tags.
|
||||
|
||||
In this example, that is the DDL portion of the `baselines/cql-keyvalue` workload.
|
||||
|
||||
`host=...` tells DSBench how to connect to your database, only one host is necessary.
|
||||
`host=...` tells nosqlbench how to connect to your database, only one host is necessary.
|
||||
|
||||
If you like, you can verify the result of this command by decribing your keyspace in cqlsh or DataStax Studio with `DESCRIBE KEYSPACE baselines`.
|
||||
|
||||
@ -49,7 +49,7 @@ If you like, you can verify the result of this command by decribing your keyspac
|
||||
|
||||
Before running a test of typical access patterns where you want to capture the results, you need to make the test more interesting than loading an empty table. For this, we use the rampup phase.
|
||||
|
||||
Before sending our test writes to the database, we will use the `stdout` activity type so we can see what DSBench is generating for CQL statements.
|
||||
Before sending our test writes to the database, we will use the `stdout` activity type so we can see what nosqlbench is generating for CQL statements.
|
||||
|
||||
Go ahead and execute the following command:
|
||||
|
||||
@ -70,7 +70,7 @@ insert into baselines.keyvalue (key, value) values (8,296173906);
|
||||
insert into baselines.keyvalue (key, value) values (9,97405552);
|
||||
```
|
||||
|
||||
One thing to know is that DSBench deterministically generates data, so the generated values will be the same from run to run.
|
||||
One thing to know is that nosqlbench deterministically generates data, so the generated values will be the same from run to run.
|
||||
|
||||
Now we are ready to write some data to our database. Go ahead and execute the following from your command line:
|
||||
|
||||
@ -140,12 +140,12 @@ We have a few new command line options here:
|
||||
|
||||
`tags=phase:main` is using a new block in our activity's yaml that contains both read and write queries.
|
||||
|
||||
`threads=50` is an important one. The default for DSBench is to run with a single thread. This is not adequate for workloads that will be running many operations, so threads is used as a way to increase concurrency on the client side.
|
||||
`threads=50` is an important one. The default for nosqlbench is to run with a single thread. This is not adequate for workloads that will be running many operations, so threads is used as a way to increase concurrency on the client side.
|
||||
|
||||
`cyclerate=5000` is used to control the operations per second that are initiated by DSBench. This command line option is the primary means to rate limit the workload and here we are running at 5000 ops/sec.
|
||||
`cyclerate=5000` is used to control the operations per second that are initiated by nosqlbench. This command line option is the primary means to rate limit the workload and here we are running at 5000 ops/sec.
|
||||
|
||||
## Now What?
|
||||
|
||||
Note in the above output, we see `Logging to logs/scenario_20190812_154431_028.log`.
|
||||
|
||||
By default DSBench records the metrics from the run in this file, we will go into detail about these metrics in the next section Viewing Results.
|
||||
By default nosqlbench records the metrics from the run in this file, we will go into detail about these metrics in the next section Viewing Results.
|
||||
|
||||
@ -5,14 +5,14 @@ weight: 3
|
||||
|
||||
# 3. Getting Results
|
||||
|
||||
Coming off of our first run with DSBench, we ran a very simple workload against our database. In that example, we saw that DSBench writes to a log file and it is in that log file where the most basic form of metrics are displayed.
|
||||
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.
|
||||
|
||||
## Log File Metrics
|
||||
|
||||
For our previous run, we saw that DSBench was writing to `logs/scenario_20190812_154431_028.log`
|
||||
For our previous run, we saw that nosqlbench was writing to `logs/scenario_20190812_154431_028.log`
|
||||
|
||||
Even when you don't configure DSBench 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 DSBench shuts down, it will flush the partial reporting interval again to the logs. This means you can always
|
||||
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
|
||||
@ -32,7 +32,7 @@ Below is a sample of the log that gives us our basic metrics. There is a lot to
|
||||
```
|
||||
|
||||
|
||||
The log contains lots of information on metrics, but this is obviously _not_ the most desirable way to consume metrics from DSBench.
|
||||
The log contains lots of information on metrics, but this is obviously _not_ the most desirable way to consume metrics from nosqlbench.
|
||||
|
||||
We recommend that you use one of these methods, according to your environment or tooling available:
|
||||
|
||||
|
||||
@ -5,7 +5,7 @@ weight: 4
|
||||
|
||||
# 4. Reading Metrics
|
||||
|
||||
A set of core metrics are provided for every workload that runs with DSBench, 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
|
||||
|
||||
@ -29,7 +29,7 @@ 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 DSBench 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
|
||||
```
|
||||
@ -38,14 +38,14 @@ TODO: talk about mix of read / writes and how that affects this metric
|
||||
|
||||
#### metric: tries
|
||||
|
||||
DSBench 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 < 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.
|
||||
```
|
||||
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
|
||||
```
|
||||
|
||||
### More Metrics
|
||||
|
||||
DSBench extends many ways to report the metrics from a run, including:
|
||||
nosqlbench extends many ways to report the metrics from a run, including:
|
||||
|
||||
- Built-in Docker Dashboard
|
||||
- Reporting to CSV
|
||||
@ -59,5 +59,5 @@ To get more information on these options, see the output of
|
||||
|
||||
### Congratulations
|
||||
|
||||
You have completed your first run with DSBench! 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! Let's head over to the Next Steps section < link > to talk about the possibilities that are now at our fingertips.
|
||||
|
||||
|
||||
@ -9,7 +9,7 @@ Now that you've run nosqlbench for the first time and seen what it does, you can
|
||||
|
||||
The sections below describe key areas that users typically customize when working with nosqlbench.
|
||||
|
||||
Everyone who uses DSBench will want to get familiar with the basics section below. This is essential reading for new and experienced testers alike.
|
||||
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
|
||||
|
||||
@ -17,7 +17,7 @@ Several canonical workloads are already baked-in to nosqlbench for immediate use
|
||||
|
||||
Recommended reading for this is:
|
||||
1. 'Built-In Workloads'
|
||||
2. 'DSBench Basics'
|
||||
2. 'nosqlbench Basics'
|
||||
|
||||
## Workload Builders
|
||||
|
||||
@ -25,7 +25,7 @@ If you want to use nosqlbench to build a tailored workload that closely emulates
|
||||
|
||||
The recommended reading for this is:
|
||||
|
||||
1. 'DSBench Basics'
|
||||
1. 'nosqlbench Basics'
|
||||
2. All of the 'Designing Workloads' section.
|
||||
3. The online examples (find the links in the Designing Workloads section.)
|
||||
|
||||
|
||||
@ -5,5 +5,5 @@ weight: 20
|
||||
|
||||
# Getting Started
|
||||
|
||||
In this Getting Started track, we will walk you through your first test run with DSBench 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.
|
||||
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,9 +1,9 @@
|
||||
---
|
||||
title: DSBench CLI Options
|
||||
title: nosqlbench CLI Options
|
||||
weight: 01
|
||||
---
|
||||
|
||||
# DSBench CLI Options
|
||||
# nosqlbench CLI Options
|
||||
|
||||
This is the same documentation you get in markdown format with the
|
||||
`nb --help` command.
|
||||
|
||||
@ -4,14 +4,14 @@ weight: 2
|
||||
---
|
||||
|
||||
# (docker-based) Grafana Metrics
|
||||
DSBench comes with a built-in helper to get you up and running quickly
|
||||
nosqlbench comes with a built-in helper to get you up and running quickly
|
||||
with client-side testing metrics.
|
||||
|
||||
:::warning
|
||||
This feature requires that you have docker running on the local system and that your user is in a group that is allowed to manage docker. Using the `--docker-metrics` command *will* attempt to manage docker on your local system.
|
||||
:::
|
||||
|
||||
To ask DSBench to stand up your metrics infrastructure using a local docker runtime, use this command line option with any other DSBench commands:
|
||||
To ask nosqlbench to stand up your metrics infrastructure using a local docker runtime, use this command line option with any other nosqlbench commands:
|
||||
|
||||
--docker-metrics
|
||||
|
||||
|
||||
@ -5,16 +5,16 @@ weight: 03
|
||||
|
||||
# Parameter Types
|
||||
|
||||
To configure an DSBench activity to do something meaningful, you have to
|
||||
provide parameters to it. This can occur in one of several ways. This section is a guide on DSBench parameters, how they layer together, and when to use one form over another.
|
||||
To configure an nosqlbench activity to do something meaningful, you have to
|
||||
provide parameters to it. This can occur in one of several ways. This section is a guide on nosqlbench parameters, how they layer together, and when to use one form over another.
|
||||
|
||||
The command line is used to configure both the overall DSBench runtime (logging, etc) as well as the individual activities and scripts. Global DSBench options can be distinguished from scenario commands and their parameters because because global options always start with a single or --double-hyphen.
|
||||
The command line is used to configure both the overall nosqlbench runtime (logging, etc) as well as the individual activities and scripts. Global nosqlbench options can be distinguished from scenario commands and their parameters because because global options always start with a single or --double-hyphen.
|
||||
|
||||
## Activity Parameters
|
||||
|
||||
Parameters for an activity always have the form of `<name>=<value>` on the command line. Activity parameters *must* follow a command, such as `run` or `start`, for example. Scenario commands are always single words without any leading hyphens. Every command-line argument that follows a scenario command in the form of `<name>=<value>` is a parameter to that command.
|
||||
|
||||
Activity parameters can be provided by the DSBench core runtime or they can be provided by the activity type. All of the params are usable to configure an activity together. It's not important where they are provided from so long as you know what they do for your workloads, how to configure them, and where to find the docs.
|
||||
Activity parameters can be provided by the nosqlbench core runtime or they can be provided by the activity type. All of the params are usable to configure an activity together. It's not important where they are provided from so long as you know what they do for your workloads, how to configure them, and where to find the docs.
|
||||
|
||||
*Core* Activity Parameters are those provided by the core runtime.
|
||||
They are part of the core API and used by every activity type. Core activity params include type*, *alias*, and *threads*, for example.
|
||||
@ -36,7 +36,7 @@ standard YAML, then you may use a mechanism called _template parameters_. These
|
||||
|
||||
Now that we've described all the parameter types, let's tie them together. When an activity is loaded from the command line or script, the parameters are resolved in the following order:
|
||||
|
||||
1. The `type` parameter tells DSBench which activity type implementation to load.
|
||||
1. The `type` parameter tells nosqlbench which activity type implementation to load.
|
||||
2. The activity type implementation creates an activity.
|
||||
3. The activity is initialized with the parameters provided.
|
||||
4. The yaml parameter is used to load the workload definition into
|
||||
|
||||
@ -10,7 +10,7 @@ either on the command line or via a scenario script. On the command line, these
|
||||
|
||||
<paramname>=<paramvalue>
|
||||
|
||||
Some activity parameters are universal in that they can be used with any activity type. These parameters are recognized by DSBench whether or not they are recognized by a particular activity type implementation. These are called _core parameters_. Only core activity parameters are documented here.
|
||||
Some activity parameters are universal in that they can be used with any activity type. These parameters are recognized by nosqlbench whether or not they are recognized by a particular activity type implementation. These are called _core parameters_. Only core activity parameters are documented here.
|
||||
|
||||
:::info
|
||||
To see what activity parameters are valid for a given activity type, see the documentation for that activity type with `nosqlbench help <activity type>`.
|
||||
@ -25,7 +25,7 @@ To see what activity parameters are valid for a given activity type, see the doc
|
||||
|
||||
Every activity is powered by a named ActivityType. Thus, you must set the `type` parameter. If you do not specify this parameter, it will be inferred from a substring match against the alias and/or yaml parameters. If there is more than one valid match for a valid type value, then you must set the type parameter directly.
|
||||
|
||||
Telling DSBench what type of an activity will be run also determines what other parameters are considered valid and how they will be used. So in this way, the type parameter is actually the base parameter for any activity. When used with scenario commands like `run` or `start`, an activity of the named type will be initialized, and then further activity parameters on the command line will be used to configure it before it is started.
|
||||
Telling nosqlbench what type of an activity will be run also determines what other parameters are considered valid and how they will be used. So in this way, the type parameter is actually the base parameter for any activity. When used with scenario commands like `run` or `start`, an activity of the named type will be initialized, and then further activity parameters on the command line will be used to configure it before it is started.
|
||||
|
||||
## alias
|
||||
|
||||
@ -52,13 +52,13 @@ _default value_ : The name of any provided YAML filename is used as the basis fo
|
||||
|
||||
You *should* set the _threads_ parameter when you need to ramp up a workload.
|
||||
|
||||
Each activity can be created with a number of threads. It is important to adjust this setting to the system types used by DSBench.
|
||||
Each activity can be created with a number of threads. It is important to adjust this setting to the system types used by nosqlbench.
|
||||
|
||||
_default value_ : For now, the default is simply *1*. Users must be aware of
|
||||
this setting and adjust it to a reasonable value for their workloads.
|
||||
|
||||
:::info
|
||||
The threads parameter will work slightly differently for activities using the async parameter. For example, when `async=500` is provided, then the number of async operations is split between all configured threads, and each thread will juggle a number of in-flight operations asynchronously. Without the async parameter, threads determines the logical concurrency level of DSBench in the classic 'request-per-thread' mode. Neither mode is strictly correct, and both modes can be used for more accurate testing depending on the constraints of your environment.
|
||||
The threads parameter will work slightly differently for activities using the async parameter. For example, when `async=500` is provided, then the number of async operations is split between all configured threads, and each thread will juggle a number of in-flight operations asynchronously. Without the async parameter, threads determines the logical concurrency level of nosqlbench in the classic 'request-per-thread' mode. Neither mode is strictly correct, and both modes can be used for more accurate testing depending on the constraints of your environment.
|
||||
:::
|
||||
|
||||
A good rule of thumb for setting threads for maximum effect is to set it relatively high, such as 10XvCPU when running synchronous workloads (when not providing the async parameter), and to 5XvCPU for all async workloads. Variation in system dynamics make it difficult to peg an ideal number, so experimentation is encouraged while you dial in your settings initially.
|
||||
@ -85,7 +85,7 @@ In the `cycles=<cycle count>` version, the count indicates the total number of c
|
||||
- _required_: no
|
||||
- _dynamic_: no
|
||||
|
||||
Usually, you don't want to provide a setting for stride, but it is still important to understand what it does. Within DSBench, each time a thread needs to allocate a set of cycles to operate on, it takes a contiguous range of values from a shared atomic value. Thus, the stride is the unit of micro-batching within DSBench. It also means that you can use stride to optimize a workload by setting the value higher than the default. For example if you are running a single-statement workload at a very high rate, it doesn't make sense for threads to allocate one op at a time from a shared atomic value. You can simply set `stride=1000` to cause (ballpark estimation) about 1000X less internal contention.
|
||||
Usually, you don't want to provide a setting for stride, but it is still important to understand what it does. Within nosqlbench, each time a thread needs to allocate a set of cycles to operate on, it takes a contiguous range of values from a shared atomic value. Thus, the stride is the unit of micro-batching within nosqlbench. It also means that you can use stride to optimize a workload by setting the value higher than the default. For example if you are running a single-statement workload at a very high rate, it doesn't make sense for threads to allocate one op at a time from a shared atomic value. You can simply set `stride=1000` to cause (ballpark estimation) about 1000X less internal contention.
|
||||
|
||||
The stride is initialized to the calculated sequence length. The sequence length is simply the number of operations in the op sequence that is planned from your active statements and their ratios.
|
||||
|
||||
@ -136,7 +136,7 @@ This is only an optional part of the cyclerate as shown in examples above. If yo
|
||||
_default_: `1.1`
|
||||
_dynamic_: yes
|
||||
|
||||
The DSBench rate limiter provides a sliding scale between strict rate limiting and average rate limiting. The difference between them is controlled by a _burst ratio_ parameter. When the burst ratio is 1.0 (burst up to 100% relative rate), the rate limiter acts as a strict rate limiter, disallowing faster operations from using time that was previously forfeited by prior slower operations. This is a "use it or lose it" mode that means things like GC events can steal throughput from a running client as a necessary effect of losing time in a strict timing sense.
|
||||
The nosqlbench rate limiter provides a sliding scale between strict rate limiting and average rate limiting. The difference between them is controlled by a _burst ratio_ parameter. When the burst ratio is 1.0 (burst up to 100% relative rate), the rate limiter acts as a strict rate limiter, disallowing faster operations from using time that was previously forfeited by prior slower operations. This is a "use it or lose it" mode that means things like GC events can steal throughput from a running client as a necessary effect of losing time in a strict timing sense.
|
||||
|
||||
When the burst ratio is set to higher than 1.0, faster operations may recover lost time from previously slower operations. For example, a burst ratio of 1.3 means that the rate limiter will allow bursting up to 130% of the base rate, but only until the average rate is back to 100% relative speed. This means that any valleys created in the actual op rate of the client can be converted into plateaus of throughput above the strict rate, but only at a speed that fits within (op rate * burst ratio). This allows for workloads to approximate the average target rate over time, with controllable bursting rates. This ability allows for near-strict behavior while allowing clients to still track truer to rate limit expectations, so long as the overall workload is not saturating resources.
|
||||
|
||||
@ -154,7 +154,7 @@ The default burst ratio of 1.1 makes testing results slightly more stable on ave
|
||||
|
||||
The `striderate` parameter allows you to limit the start of a stride according to some rate. This works almost exactly like the cyclerate parameter, except that it blocks a whole group of operations from starting instead of a single operation. The striderate can use a burst ratio just as the cyclerate.
|
||||
|
||||
This sets the target rate for strides. In DSBench, a stride is a group of
|
||||
This sets the target rate for strides. In nosqlbench, a stride is a group of
|
||||
operations that are dispatched and executed together within the same thread.
|
||||
This is useful, for example, to emulate application behaviors in which some
|
||||
outside request translates to multiple internal requests. It is also a way
|
||||
|
||||
@ -5,7 +5,7 @@ weight: 06
|
||||
|
||||
# Core Statement Parameters
|
||||
|
||||
Some statement parameters are recognized by the DSBench runtime and can be used on any statement in a YAML file.
|
||||
Some statement parameters are recognized by the nosqlbench runtime and can be used on any statement in a YAML file.
|
||||
|
||||
## *ratio*
|
||||
|
||||
|
||||
@ -1,8 +1,8 @@
|
||||
---
|
||||
title: DSBench Basics
|
||||
title: nosqlbench Basics
|
||||
weight: 30
|
||||
---
|
||||
|
||||
This section covers the essential details that you'll need to
|
||||
run DSBench in different ways.
|
||||
run nosqlbench in different ways.
|
||||
|
||||
|
||||
@ -13,7 +13,7 @@ built-in workloads. It is strongly advised that new workload YAMLs use the same
|
||||
|
||||
### Schema phase
|
||||
|
||||
The schema phase is simply a phase of your test which creates the necessary schema on your target system. For CQL, this generally consists of a keyspace and one ore more table statements. There is no special schema layer in DSBench. All statements executed are simply statements. This provides the greatest flexibility in testing since every activity type is allowed to control its DDL and DML using the same machinery.
|
||||
The schema phase is simply a phase of your test which creates the necessary schema on your target system. For CQL, this generally consists of a keyspace and one ore more table statements. There is no special schema layer in nosqlbench. All statements executed are simply statements. This provides the greatest flexibility in testing since every activity type is allowed to control its DDL and DML using the same machinery.
|
||||
|
||||
The schema phase is normally executed with defaults for most parameters. This means that statements will execute in the order specified in the YAML, in serialized form, exactly once. This is a welcome side-effect of how the initial parameters like _cycles_ is set from the statements which are activated by tagging.
|
||||
|
||||
@ -37,7 +37,7 @@ You can mark statements as rampup phase statements by adding this set of tags to
|
||||
|
||||
### Main phase
|
||||
|
||||
The main phase of a DSBench scenario is the one during which you really care about the metric. This is the actual test that everything else has prepared your system for.
|
||||
The main phase of a nosqlbench scenario is the one during which you really care about the metric. This is the actual test that everything else has prepared your system for.
|
||||
|
||||
You can mark statement as schema phase statements by adding this set of tags to the statements, either directly, or by block:
|
||||
|
||||
|
||||
@ -5,7 +5,7 @@ weight: 02
|
||||
|
||||
## Data Bindings
|
||||
|
||||
Procedural data generation is built-in to the DSBench runtime by way of the [Virtual DataSet](http://virtdata.io/) library. This allows us to create named data generation recipes. These named recipes for generated data are called bindings. Procedural generation for test data has [many benefits](http://docs.virtdata.io/why_virtdata/why_virtdata/) over shipping bulk test data around, including speed and deterministic behavior. With the VirtData approach, most of the hard work is already done for us. We just have to pull in the recipes we want.
|
||||
Procedural data generation is built-in to the nosqlbench runtime by way of the [Virtual DataSet](http://virtdata.io/) library. This allows us to create named data generation recipes. These named recipes for generated data are called bindings. Procedural generation for test data has [many benefits](http://docs.virtdata.io/why_virtdata/why_virtdata/) over shipping bulk test data around, including speed and deterministic behavior. With the VirtData approach, most of the hard work is already done for us. We just have to pull in the recipes we want.
|
||||
|
||||
You can add a bindings section like this:
|
||||
|
||||
@ -30,7 +30,7 @@ The above bindings block is also a valid activity YAML, at least for the _stdout
|
||||
delta: WeightedStrings('one:1;six:6;three:3;')
|
||||
# EOF (control-D in your terminal)
|
||||
|
||||
[test]$ nosqlbench run type=stdout yaml=stdout-test cycles=10
|
||||
[test]$ ./nb run type=stdout yaml=stdout-test cycles=10
|
||||
0,zero,00A_pro,six
|
||||
1,one,00B_pro,six
|
||||
2,two,00C_pro,three
|
||||
@ -45,7 +45,7 @@ The above bindings block is also a valid activity YAML, at least for the _stdout
|
||||
|
||||
Above, you can see that the stdout activity type is idea for experimenting with data generation recipes. It uses the default `format=csv` parameter above, but it also supports formats like json, inlinejson, readout, and assignments.
|
||||
|
||||
This is all you need to provide a formulaic recipe for converting an ordinal value to a set of field values. Each time DSBench needs to create a set of values as parameters to a statement, the functions are called with an input, known as the cycle. The functions produce a set of named values that, when combined with a statement template, can yield an individual statement for a database operation. In this way, each cycle represents a specific operation. Since the functions above are pure functions, the cycle number of an operation will always produce the same operation, thus making all DSBench workloads deterministic.
|
||||
This is all you need to provide a formulaic recipe for converting an ordinal value to a set of field values. Each time nosqlbench needs to create a set of values as parameters to a statement, the functions are called with an input, known as the cycle. The functions produce a set of named values that, when combined with a statement template, can yield an individual statement for a database operation. In this way, each cycle represents a specific operation. Since the functions above are pure functions, the cycle number of an operation will always produce the same operation, thus making all nosqlbench workloads deterministic.
|
||||
|
||||
In the example above, you can see the cycle numbers down the left.
|
||||
|
||||
@ -66,7 +66,7 @@ bindings:
|
||||
delta: WeightedStrings('one:1;six:6;three:3;')
|
||||
# EOF (control-D in your terminal)
|
||||
|
||||
[test]$ nosqlbench run type=stdout yaml=stdout-test cycles=10
|
||||
[test]$ ./nb run type=stdout yaml=stdout-test cycles=10
|
||||
This is a statement, and the file format doesn't
|
||||
know how statements will be used!
|
||||
submit job 1 on queue one with options 00B_pro;
|
||||
|
||||
@ -40,39 +40,39 @@ statements:
|
||||
# EOF (control-D in your terminal)
|
||||
|
||||
# no tag filter matches any
|
||||
[test]$ nosqlbench run type=stdout yaml=stdout-test
|
||||
[test]$ ./nb run type=stdout yaml=stdout-test
|
||||
I'm alive!
|
||||
|
||||
# tag name assertion matches
|
||||
[test]$ nosqlbench run type=stdout yaml=stdout-test tags=name
|
||||
[test]$ ./nb run type=stdout yaml=stdout-test tags=name
|
||||
I'm alive!
|
||||
|
||||
# tag name assertion does not match
|
||||
[test]$ nosqlbench run type=stdout yaml=stdout-test tags=name2
|
||||
[test]$ ./nb run type=stdout yaml=stdout-test tags=name2
|
||||
02:25:28.158 [scenarios:001] ERROR i.e.activities.stdout.StdoutActivity - Unable to create a stdout statement if you have no active statements or bindings configured.
|
||||
|
||||
# tag value assertion does not match
|
||||
[test]$ nosqlbench run type=stdout yaml=stdout-test tags=name:bravo
|
||||
[test]$ ./nb run type=stdout yaml=stdout-test tags=name:bravo
|
||||
02:25:42.584 [scenarios:001] ERROR i.e.activities.stdout.StdoutActivity - Unable to create a stdout statement if you have no active statements or bindings configured.
|
||||
|
||||
# tag value assertion matches
|
||||
[test]$ nosqlbench run type=stdout yaml=stdout-test tags=name:foxtrot
|
||||
[test]$ ./nb run type=stdout yaml=stdout-test tags=name:foxtrot
|
||||
I'm alive!
|
||||
|
||||
# tag pattern assertion matches
|
||||
[test]$ nosqlbench run type=stdout yaml=stdout-test tags=name:'fox.*'
|
||||
[test]$ ./nb run type=stdout yaml=stdout-test tags=name:'fox.*'
|
||||
I'm alive!
|
||||
|
||||
# tag pattern assertion does not match
|
||||
[test]$ nosqlbench run type=stdout yaml=stdout-test tags=name:'tango.*'
|
||||
[test]$ ./nb run type=stdout yaml=stdout-test tags=name:'tango.*'
|
||||
02:26:05.149 [scenarios:001] ERROR i.e.activities.stdout.StdoutActivity - Unable to create a stdout statement if you have no active statements or bindings configured.
|
||||
|
||||
# compound tag predicate matches every assertion
|
||||
[test]$ nosqlbench run type=stdout yaml=stdout-test tags='name=fox.*',unit=bravo
|
||||
[test]$ ./nb run type=stdout yaml=stdout-test tags='name=fox.*',unit=bravo
|
||||
I'm alive!
|
||||
|
||||
# compound tag predicate does not fully match
|
||||
[test]$ nosqlbench run type=stdout yaml=stdout-test tags='name=fox.*',unit=delta
|
||||
[test]$ ./nb run type=stdout yaml=stdout-test tags='name=fox.*',unit=delta
|
||||
11:02:53.490 [scenarios:001] ERROR i.e.activities.stdout.StdoutActivity - Unable to create a stdout statement if you have no active statements or bindings configured.
|
||||
|
||||
|
||||
|
||||
@ -25,7 +25,7 @@ blocks:
|
||||
beta: Combinations('b;l;o;c;k;2;-;COMBINATIONS;')
|
||||
# EOF (control-D in your terminal)
|
||||
|
||||
[test]$ nosqlbench run type=stdout yaml=stdout-test cycles=10
|
||||
[test]$ ./nb run type=stdout yaml=stdout-test cycles=10
|
||||
0,block1-C
|
||||
1,block2-O
|
||||
2,block1-M
|
||||
|
||||
@ -113,5 +113,5 @@ statements:
|
||||
|
||||
Specifically, the first statement is a simple statement body, the second is a named statement (via free param `<name>: statement` form), the third is a statement config map, and the fourth is a combination of the previous two.
|
||||
|
||||
The above is valid DSBench YAML, although a reader would need
|
||||
The above is valid nosqlbench YAML, although a reader would need
|
||||
to know about the rules explained above in order to really make sense of it. For most cases, it is best to follow one format convention, but there is flexibility for overrides and naming when you need it.
|
||||
|
||||
@ -29,7 +29,7 @@ bindings:
|
||||
statements:
|
||||
- "doc2.number {numname}\n"
|
||||
# EOF (control-D in your terminal)
|
||||
[test]$ nosqlbench run type=stdout yaml=stdout-test cycles=10
|
||||
[test]$ ./nb run type=stdout yaml=stdout-test cycles=10
|
||||
doc1.form1 doc1.1
|
||||
doc1.form2 doc1.2
|
||||
doc2.number two
|
||||
|
||||
@ -5,7 +5,7 @@ weight: 08
|
||||
|
||||
# Template Params
|
||||
|
||||
All DSBench YAML formats support a parameter macro format that applies before YAML processing starts. It is a basic macro facility that allows named anchors to be placed in the document as a whole:
|
||||
All nosqlbench YAML formats support a parameter macro format that applies before YAML processing starts. It is a basic macro facility that allows named anchors to be placed in the document as a whole:
|
||||
|
||||
```text
|
||||
<<varname:defaultval>>
|
||||
@ -21,10 +21,10 @@ statements:
|
||||
- "<<linetoprint:MISSING>>\n"
|
||||
# EOF (control-D in your terminal)
|
||||
|
||||
[test]$ nosqlbench run type=stdout yaml=stdout-test cycles=1
|
||||
[test]$ ./nb run type=stdout yaml=stdout-test cycles=1
|
||||
MISSING
|
||||
|
||||
[test]$ nosqlbench run type=stdout yaml=stdout-test cycles=1 linetoprint="THIS IS IT"
|
||||
[test]$ ./nb run type=stdout yaml=stdout-test cycles=1 linetoprint="THIS IS IT"
|
||||
THIS IS IT
|
||||
```
|
||||
|
||||
|
||||
@ -5,27 +5,27 @@ weight: 40
|
||||
|
||||
# Designing Workloads
|
||||
|
||||
Workloads in DSBench are always controlled by a workload definition. Even the built-in workloads are simply pre-configured and controlled from a single YAML file which is bundled internally.
|
||||
Workloads in nosqlbench are always controlled by a workload definition. Even the built-in workloads are simply pre-configured and controlled from a single YAML file which is bundled internally.
|
||||
|
||||
With DSBench a standard YAML configuration format is provided that is used across all activity types. This makes it easy to specify statements, statement parameters, data bindings, and tags. This section describes the standard YAML format and how to use it.
|
||||
With nosqlbench a standard YAML configuration format is provided that is used across all activity types. This makes it easy to specify statements, statement parameters, data bindings, and tags. This section describes the standard YAML format and how to use it.
|
||||
|
||||
It is recommended that you read through the examples in each of the design sections in order. This guide was designed to give you a detailed understanding of workload construction with DSBench. The examples will also give you better insight into how DSBench works at a fundamental level.
|
||||
It is recommended that you read through the examples in each of the design sections in order. This guide was designed to give you a detailed understanding of workload construction with nosqlbench. The examples will also give you better insight into how nosqlbench works at a fundamental level.
|
||||
|
||||
## Multi-Protocol Support
|
||||
|
||||
You will notice that this guide is not overly CQL-specific. That is because DSBench is a multi-protocol tool. All that is needed for you to use this guide with other protocols is the release of more activity types. Try to keep that in mind as you think about designing workloads.
|
||||
You will notice that this guide is not overly CQL-specific. That is because nosqlbench is a multi-protocol tool. All that is needed for you to use this guide with other protocols is the release of more activity types. Try to keep that in mind as you think about designing workloads.
|
||||
|
||||
## Advice for new builders
|
||||
|
||||
### Review existing examples
|
||||
|
||||
The built-in workloads that are include with DSBench are also shared on the github site where we manage the DSBench project:
|
||||
The built-in workloads that are include with nosqlbench are also shared on the github site where we manage the nosqlbench project:
|
||||
|
||||
- [baselines](https://github.com/datastax/nosqlbench-labs/tree/master/sample-activities/baselines)
|
||||
- [bindings](https://github.com/datastax/nosqlbench-labs/tree/master/sample-activities/bindings)
|
||||
|
||||
### Follow the conventions
|
||||
|
||||
The tagging conventions described under the YAML Conventions section will make your testing go smoother. All of the baselines that we publish for DSBench will use this form.
|
||||
The tagging conventions described under the YAML Conventions section will make your testing go smoother. All of the baselines that we publish for nosqlbench will use this form.
|
||||
|
||||
|
||||
|
||||
@ -3,7 +3,7 @@ title: Activity Types
|
||||
weight: 50
|
||||
---
|
||||
|
||||
Each DSBench scenario is comprised of one or more activities of a specific type. The types of activities available are provided by the version of DSBench.
|
||||
Each nosqlbench scenario is comprised of one or more activities of a specific type. The types of activities available are provided by the version of nosqlbench.
|
||||
|
||||
Additional activity types will be added in future releases. This section is a reference section that shows the help you would get with a command like:
|
||||
|
||||
|
||||
@ -10,14 +10,14 @@ The EngineBlock runtime is a combination of a scripting sandbox and a workload e
|
||||
|
||||
## Machinery, Controls & Instruments
|
||||
|
||||
All of the heavy lifting is left to Java and the core DSBench runtime. This includes the iterative workloads that are meant to test the target system. This is combined with a control layer which is provided by Nashorn and eventually GraalVM. This division of responsibility allows the high-level test logic to be "script" and the low-level activity logic to be "machinery". While the scenario script has the most control, it also is the least busy relative to activity workloads. The net effect is that you have the efficiency of the iterative test loads in conjunction with the open design palette of a first-class scripting language.
|
||||
All of the heavy lifting is left to Java and the core nosqlbench runtime. This includes the iterative workloads that are meant to test the target system. This is combined with a control layer which is provided by Nashorn and eventually GraalVM. This division of responsibility allows the high-level test logic to be "script" and the low-level activity logic to be "machinery". While the scenario script has the most control, it also is the least busy relative to activity workloads. The net effect is that you have the efficiency of the iterative test loads in conjunction with the open design palette of a first-class scripting language.
|
||||
|
||||
Essentially, the ActivityType drivers are meant to handle the workload-specific machinery. They also provide dynamic control points and parameters which special to that activity type. This exposes a full feedback loop between a running scenario script and the activities that it runs. The scenario is free to read the performance metrics from a running activity and make changes to it on the fly.
|
||||
|
||||
## Scripting Environment
|
||||
|
||||
The DSBench scripting environment provided has a few
|
||||
modifications meant to streamline understanding and usage of DSBench dynamic parameters and metric.
|
||||
The nosqlbench scripting environment provided has a few
|
||||
modifications meant to streamline understanding and usage of nosqlbench dynamic parameters and metric.
|
||||
|
||||
### Active Bindings
|
||||
|
||||
@ -40,7 +40,7 @@ Each activity metric for a given activity alias is available at this name.
|
||||
This gives you access to the metrics objects directly. Some metrics objects
|
||||
have also been enhanced with wrapper logic to provide simple getters and setters, like `.p99ms` or `.p99ns`, for example.
|
||||
|
||||
Interaction with the DSBench runtime and the activities therein is made easy
|
||||
Interaction with the nosqlbench runtime and the activities therein is made easy
|
||||
by the above variables and objects. When an assignment is made to any of these variables, the changes are propagated to internal listeners. For changes to _threads_, the thread pool responsible for the affected activity adjusts the number of active threads (AKA slots). Other changes are further propagated directly to the thread harnesses and components which implement the ActivityType.
|
||||
|
||||
:::warning
|
||||
@ -52,7 +52,7 @@ mixing then with the runtime controls provided above.
|
||||
|
||||
## Enhanced Metrics for Scripting
|
||||
|
||||
The metrics available in DSBench are slightly different than the standard
|
||||
The metrics available in nosqlbench are slightly different than the standard
|
||||
kit with dropwizard metrics. The key differences are:
|
||||
|
||||
### HDR Histograms
|
||||
@ -80,7 +80,7 @@ When a script is run, it has absolute control over the scenario runtime while it
|
||||
|
||||
## Strategies
|
||||
|
||||
You can use DSBench in the classic form with `run type=<type> param=value ...` command line syntax. There are reasons, however, that you will sometimes want customize and modify your scripts directly, such as:
|
||||
You can use nosqlbench in the classic form with `run type=<type> param=value ...` command line syntax. There are reasons, however, that you will sometimes want customize and modify your scripts directly, such as:
|
||||
|
||||
- Permute test variables to cover many sub-conditions in a test.
|
||||
- Automatically adjust load factors to identify the nominal capacity of a system.
|
||||
|
||||
@ -4,21 +4,21 @@ title: Standard Metrics
|
||||
|
||||
# Standard Metrics
|
||||
|
||||
DSBench comes with a set of standard metrics that will be part of every activity type. Each activity type enhances the metrics available by adding their own metrics with the DSBench APIs. This section explains what the standard metrics are, and how to interpret them.
|
||||
nosqlbench comes with a set of standard metrics that will be part of every activity type. Each activity type enhances the metrics available by adding their own metrics with the nosqlbench APIs. This section explains what the standard metrics are, and how to interpret them.
|
||||
|
||||
## read-input
|
||||
|
||||
Within DSBench, a data stream provider called an _Input_ is responsible for providing the actual cycle number that will be used by consumer threads. Because different _Input_ implementations may perform differently, a separate metric is provided to track the performance in terms of client-side overhead. The **read-input** metric is a timer that only measured the time it takes for a given activity thread to read the input value, nothing more.
|
||||
Within nosqlbench, a data stream provider called an _Input_ is responsible for providing the actual cycle number that will be used by consumer threads. Because different _Input_ implementations may perform differently, a separate metric is provided to track the performance in terms of client-side overhead. The **read-input** metric is a timer that only measured the time it takes for a given activity thread to read the input value, nothing more.
|
||||
|
||||
## strides
|
||||
|
||||
A stride represents the work-unit for a thread within DSBench. It allows a set of cycles to be logically grouped together for purposes of optimization -- or in some cases -- to simulate realistic client-side behavior over multiple operations. The stride is the number of cycles that will be allocated to each thread before it starts iterating on them.
|
||||
A stride represents the work-unit for a thread within nosqlbench. It allows a set of cycles to be logically grouped together for purposes of optimization -- or in some cases -- to simulate realistic client-side behavior over multiple operations. The stride is the number of cycles that will be allocated to each thread before it starts iterating on them.
|
||||
|
||||
The **strides** timer measures the time each stride takes, including all cycles within the stride. It starts measuring time before the cycle starts, and stops measuring after the last cycle in the stride has run.
|
||||
|
||||
## cycles
|
||||
|
||||
Within DSBench, each logical iteration of a statement is handled within a distinct cycle. A cycle represents an iteration of a workload. This corresponds to a single operation executed according to some statement definition.
|
||||
Within nosqlbench, each logical iteration of a statement is handled within a distinct cycle. A cycle represents an iteration of a workload. This corresponds to a single operation executed according to some statement definition.
|
||||
|
||||
The **cycles** metric is a timer that starts counting at the start of a cycle, before any specific activity behavior has control. It stops timing once the logical cycle is complete. This includes and additional phases that are executed by multi-phase actions.
|
||||
|
||||
|
||||
@ -5,17 +5,17 @@ title: Timing Terms
|
||||
# Timing Terms
|
||||
|
||||
Often, terms used to describe latency can create confusion.
|
||||
In fact, the term _latency_ is so overloaded in practice that it is not useful by itself. Because of this, DSBench will avoid using the term latency _except in a specific way_. Instead, the terms described in this section will be used.
|
||||
In fact, the term _latency_ is so overloaded in practice that it is not useful by itself. Because of this, nosqlbench will avoid using the term latency _except in a specific way_. Instead, the terms described in this section will be used.
|
||||
|
||||
DSBench is a client-centric testing tool. The measurement of operations occurs on the client, without visibility to what happens in transport or on the server. This means that the client *can* see how long an operation takes, but it *cannot see* how much of the operational time is spent in transport and otherwise. This has a bearing on the terms that are adopted with DSBench.
|
||||
nosqlbench is a client-centric testing tool. The measurement of operations occurs on the client, without visibility to what happens in transport or on the server. This means that the client *can* see how long an operation takes, but it *cannot see* how much of the operational time is spent in transport and otherwise. This has a bearing on the terms that are adopted with nosqlbench.
|
||||
|
||||
Some terms are anchored by the context in which they are used. For latency terms, *service time* can be subjective. When using this term to describe other effects in your system, what is included depends on the perspective of the requester. The concept of service is universal, and every layer in a system can be seen as a service. Thus, the service time is defined by the vantage point of the requester. This is the perspective taken by the DSBench approach for naming and semantics below.
|
||||
Some terms are anchored by the context in which they are used. For latency terms, *service time* can be subjective. When using this term to describe other effects in your system, what is included depends on the perspective of the requester. The concept of service is universal, and every layer in a system can be seen as a service. Thus, the service time is defined by the vantage point of the requester. This is the perspective taken by the nosqlbench approach for naming and semantics below.
|
||||
|
||||
## responsetime
|
||||
|
||||
**The duration of time a user has to wait for a response from the time they submitted the request.** Response time is the duration of time from when a request was expected to start, to the time at which the response is finally seen by the user. A request is generally expected to start immediately when users make a request. For example, when a user enters a URL into a browser, they expect the request to start immediately when they hit enter.
|
||||
|
||||
In DSBench, the response time for any operation can be calculated by adding its wait time and its the service time together.
|
||||
In nosqlbench, the response time for any operation can be calculated by adding its wait time and its the service time together.
|
||||
|
||||
## waittime
|
||||
|
||||
@ -25,5 +25,5 @@ Wait time can accumulate when you are running something according to a dispatch
|
||||
|
||||
## servicetime
|
||||
|
||||
**The duration of time it takes a server or other system to fully process to a request and send a response.** From the perspective of a testing client, the _system_ includes the infrastructure as well as remote servers. As such, the service time metrics in DSBench include any operational time that is external to the client, including transport latency.
|
||||
**The duration of time it takes a server or other system to fully process to a request and send a response.** From the perspective of a testing client, the _system_ includes the infrastructure as well as remote servers. As such, the service time metrics in nosqlbench include any operational time that is external to the client, including transport latency.
|
||||
|
||||
|
||||
@ -25,7 +25,7 @@ With the exception of the `--docker-metrics` approach, these forms may be combin
|
||||
|
||||
If you like to have all of your testing data in one place, then you may be
|
||||
interested in reporting your measurements to a monitoring system. For this,
|
||||
DSBench includes a [Metrics Library](https://github.com/dropwizard/metrics).
|
||||
nosqlbench includes a [Metrics Library](https://github.com/dropwizard/metrics).
|
||||
Graphite reporting is baked in as the default reporter.
|
||||
|
||||
In order to enable graphite reporting, use one of these options formats:
|
||||
|
||||
@ -3,4 +3,4 @@ title: Reference
|
||||
weight: 90
|
||||
---
|
||||
|
||||
This section contains additional reference details across a range of DSBench topics.
|
||||
This section contains additional reference details across a range of nosqlbench topics.
|
||||
@ -1,87 +0,0 @@
|
||||
# Virtual Dataset Concepts
|
||||
|
||||
VirtData is a library for the flexible management and expressive use of
|
||||
procedural generation libraries. It is a reincarnation of a previous project.
|
||||
This version of the idea starts by focusing directly on usage aspects and
|
||||
extension points rather than the big idea.
|
||||
|
||||
### Procedural Generation
|
||||
|
||||
Procedural generation is a general class of methods for taking a set of inputs
|
||||
and modifying them in a predictable way to generate content which appears random
|
||||
but is actually deterministic. For example, some games use procedural generation
|
||||
to take a single value known as the "seed" to generate an apparently rich and
|
||||
interesting world.
|
||||
|
||||
### Apparently Random RNGs
|
||||
|
||||
Sequences of values produced by RNGs (more properly called PRNGs) are not
|
||||
actually random, even though they may pass certain tests for randomness. In
|
||||
practice, the combination of these two properties is quite valuable for testing
|
||||
and data synthesis. Having a stream of data that is measurably random by some
|
||||
meaningful standard, but which is configurable and reusable allows for test to
|
||||
be replayed, for example.
|
||||
|
||||
### Apparently Random Samples
|
||||
|
||||
Just as RNGs can appear random when the are not truly, statistical distributions
|
||||
which rely on them can also appear random. Uniform random number generators over
|
||||
the unit interval [0,1.0) are a common input to virtual sampling methods. This
|
||||
means that if you can configure the RNG stream that you feed into your virtual
|
||||
sampling methods, you can simulate a repeatable sequence from a known
|
||||
distribution.
|
||||
|
||||
### Data Mapping Functions
|
||||
|
||||
The data mapping functions are the core building block of virtdata. They are the
|
||||
functional logic that powers all procedural generation. Data mapping functions
|
||||
are generally pure functions. This simply means that a generator function will
|
||||
always provide the same result given the same input. All top-level mapping
|
||||
functions all take a long value as their input, and produce a result based on
|
||||
their parameterized type.
|
||||
|
||||
##### Combining RNGs and Data Mapping Functions
|
||||
|
||||
Because pure functions play such a key part in procedural generation techniques,
|
||||
the terms "data mapping function", "data mapper" and "data mapping library" will
|
||||
be more common in the library than "generator". Conceptually, mapping functions
|
||||
to not generate anything. It makes more sense to think of mapping data from one
|
||||
domain to another. Even so, the data that is yielded by mapping functions can
|
||||
appear quite realistic.
|
||||
|
||||
Because good RNGs do generally contain internal state, they aren't purely
|
||||
functional. This means that in some cases -- those in which you need to have
|
||||
random access to a virtual data set, hash functions make more sense. This
|
||||
toolkit allows you to choose between the two in some cases. However, it
|
||||
generally favors using hashing and pure-function approaches where possible. Even
|
||||
the statistical curve simulations do this.
|
||||
|
||||
### Data Mapper Library
|
||||
|
||||
Data Mapping functions are packaged into libraries which can be loaded by the
|
||||
virtdata-user component of the project. Each library has a name, a function
|
||||
resolver, and a set of functions that can be instantiated via the function
|
||||
resolver.
|
||||
|
||||
### Function Resolver
|
||||
|
||||
Each library must implement its own function resolver. This is because each
|
||||
library may have a different way of naming, finding, creating or managing
|
||||
function generator instances. For the user, the description of a generator is
|
||||
simply a string. What the generator library does with it is
|
||||
implementation-specific. This means that some generator libraries may simply
|
||||
have constructor signatures as function specifiers, and others may go as far as
|
||||
implementing their own DSL. The basic contract for a function resolver is that
|
||||
you pass it a string describing what you want, and it provides a generator
|
||||
function in return.
|
||||
|
||||
#### Bindings Template
|
||||
|
||||
It is often useful to have a template that describes a set of generator
|
||||
functions that can be reused across many threads or other application scopes. A
|
||||
bindings template is a way to capture the requested generator functions for
|
||||
re-use, with actual scope instantiation of the generator functions controlled by
|
||||
the usage point. For example, in a JEE app, you may have a bindings template in
|
||||
the application scope, and a set of actual bindings within each request (thread
|
||||
scope).
|
||||
|
||||
@ -6,7 +6,7 @@
|
||||
<h1 v-else>
|
||||
{{ otherError }}
|
||||
</h1>
|
||||
<a href="https://github.com/datastax/dsbench-labs/issues/new?labels=APPUSE,UX,documentation">
|
||||
<a href="https://github.com/datastax/nosqlbench-labs/issues/new?labels=APPUSE,UX,documentation">
|
||||
File A UI Bug Report
|
||||
</a>
|
||||
<NuxtLink to="/">
|
||||
|
||||
@ -9,7 +9,7 @@ export default {
|
||||
** Headers of the page
|
||||
*/
|
||||
head: {
|
||||
titleTemplate: '%s' + "NoSqlBench Guidebook",
|
||||
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>DS Bench Documentation</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>DS Bench Documentation</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/dsbench-labs/wiki/Submitting-Feedback">SUBMIT FEEDBACK</v-btn>
|
||||
<v-btn text href="https://github.com/datastax/nosqlbench-labs/wiki/Submitting-Feedback">SUBMIT FEEDBACK</v-btn>
|
||||
</v-toolbar-items>
|
||||
</v-app-bar>
|
||||
|
||||
|
||||
@ -1,9 +1,9 @@
|
||||
<!doctype html>
|
||||
<html>
|
||||
<head>
|
||||
<title>guidebookNoSqlBench Guidebook</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/4cea5966dac98b0ba746.js" as="script"><link rel="preload" href="/_nuxt/4624bfb5c053c019954b.js" as="script"><link rel="preload" href="/_nuxt/54674d21809810cadfcb.js" as="script"><link rel="preload" href="/_nuxt/9add61b10767494b3691.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/856e5d85bfbcfcf786ae.js" as="script"><link rel="preload" href="/_nuxt/4624bfb5c053c019954b.js" as="script"><link rel="preload" href="/_nuxt/54674d21809810cadfcb.js" as="script"><link rel="preload" href="/_nuxt/5f1fda305296fff2eb15.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/4cea5966dac98b0ba746.js"></script><script type="text/javascript" src="/_nuxt/4624bfb5c053c019954b.js"></script><script type="text/javascript" src="/_nuxt/54674d21809810cadfcb.js"></script><script type="text/javascript" src="/_nuxt/9add61b10767494b3691.js"></script></body>
|
||||
<script type="text/javascript" src="/_nuxt/856e5d85bfbcfcf786ae.js"></script><script type="text/javascript" src="/_nuxt/4624bfb5c053c019954b.js"></script><script type="text/javascript" src="/_nuxt/54674d21809810cadfcb.js"></script><script type="text/javascript" src="/_nuxt/5f1fda305296fff2eb15.js"></script></body>
|
||||
</html>
|
||||
|
||||
File diff suppressed because one or more lines are too long
@ -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:"efdb07324aea334c9e80",1:"e0a04b7263a86d58d3ba",4:"7cd152161870ad867e83",5:"d3314fbbc4bf2910b26a",6:"ba88ffaeb47c59c7387b",7:"2b06a447c63ab9b99324"}[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:"efdb07324aea334c9e80",1:"e0a04b7263a86d58d3ba",4:"b1f17d3a199a3eda0e71",5:"e4bdf51517af19e13e1f",6:"ba88ffaeb47c59c7387b",7:"2b06a447c63ab9b99324"}[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
@ -1,9 +1,9 @@
|
||||
<!doctype html>
|
||||
<html>
|
||||
<head>
|
||||
<title>guidebookNoSqlBench Guidebook</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/4cea5966dac98b0ba746.js" as="script"><link rel="preload" href="/_nuxt/4624bfb5c053c019954b.js" as="script"><link rel="preload" href="/_nuxt/54674d21809810cadfcb.js" as="script"><link rel="preload" href="/_nuxt/9add61b10767494b3691.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/856e5d85bfbcfcf786ae.js" as="script"><link rel="preload" href="/_nuxt/4624bfb5c053c019954b.js" as="script"><link rel="preload" href="/_nuxt/54674d21809810cadfcb.js" as="script"><link rel="preload" href="/_nuxt/5f1fda305296fff2eb15.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/4cea5966dac98b0ba746.js"></script><script type="text/javascript" src="/_nuxt/4624bfb5c053c019954b.js"></script><script type="text/javascript" src="/_nuxt/54674d21809810cadfcb.js"></script><script type="text/javascript" src="/_nuxt/9add61b10767494b3691.js"></script></body>
|
||||
<script type="text/javascript" src="/_nuxt/856e5d85bfbcfcf786ae.js"></script><script type="text/javascript" src="/_nuxt/4624bfb5c053c019954b.js"></script><script type="text/javascript" src="/_nuxt/54674d21809810cadfcb.js"></script><script type="text/javascript" src="/_nuxt/5f1fda305296fff2eb15.js"></script></body>
|
||||
</html>
|
||||
|
||||
@ -1,25 +0,0 @@
|
||||
---
|
||||
title: Compatibility
|
||||
weight: 3
|
||||
---
|
||||
|
||||
# Binary Format
|
||||
|
||||
DSBench is distributed primarily as a binary for Linux distributions. The DSBench binary includes its own OpenJDK runtime. It should work for most modern Linux distributions. The only requirement is that fuse be installed (it is usually already present) on the client system.
|
||||
|
||||
# Supported Systems
|
||||
|
||||
DSBench runs on Linux as a binary distribution. Any modern Linux which can run AppImage binaries should work.
|
||||
|
||||
# Activity Types
|
||||
|
||||
In nosqlbench terms, this means:
|
||||
|
||||
Activity types are how DSBench gets its support for different protocols or client drivers. The initial release of DSBench includes support for
|
||||
these activity types:
|
||||
|
||||
- The CQL activity type
|
||||
- The initial release of the CQL activity type uses the DataStax driver version 1.9.0
|
||||
- The stdout activity type.
|
||||
|
||||
|
||||
@ -1,16 +0,0 @@
|
||||
---
|
||||
title: Introducing DSBench
|
||||
weight: 10
|
||||
---
|
||||
|
||||
# DataStax Bench Documentation
|
||||
|
||||
Welcome to the documentation for DataStax Bench (DSBench). DSBench 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.
|
||||
|
||||
DSBench 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 release. We will be adding docs for more advanced users to unlock based on a how-to format.
|
||||
|
||||
We take requests! If you have specific nosqlbench topics you'd like to
|
||||
have added to this guidebook, please make a request as described under the Support Options section.
|
||||
@ -0,0 +1,25 @@
|
||||
---
|
||||
title: Compatibility
|
||||
weight: 3
|
||||
---
|
||||
|
||||
# Binary Format
|
||||
|
||||
nosqlbench is distributed primarily as a binary for Linux distributions. The nosqlbench binary includes its own OpenJDK runtime. It should work for most modern Linux distributions. The only requirement is that fuse be installed (it is usually already present) on the client system.
|
||||
|
||||
# Supported Systems
|
||||
|
||||
nosqlbench runs on Linux as a binary distribution. Any modern Linux which can run AppImage binaries should work.
|
||||
|
||||
# Activity Types
|
||||
|
||||
In nosqlbench terms, this means:
|
||||
|
||||
Activity types are how nosqlbench gets its support for different protocols or client drivers. The initial release of nosqlbench includes support for
|
||||
these activity types:
|
||||
|
||||
- The CQL activity type
|
||||
- The initial release of the CQL activity type uses the DataStax driver version 1.9.0
|
||||
- The stdout activity type.
|
||||
|
||||
|
||||
@ -9,15 +9,15 @@ These guidelines are mirrored at the [Submitting Feedback](https://github.com/da
|
||||
|
||||
## Community Support
|
||||
|
||||
It is supported by a community of active users at [DataStax DSBench Community](https://community.datastax.com/spaces/51/index.html).
|
||||
It is supported by a community of active users at [DataStax nosqlbench Community](https://community.datastax.com/spaces/51/index.html).
|
||||
|
||||
## Bug Fixes
|
||||
|
||||
If you think you have found a bug, please [file a bug report](https://github.com/datastax/nosqlbench-labs/issues/new?labels=bug). DSBench is actively used within DataStax, and verified bugs will get attention as resources permit. Bugs reports which are more detailed, or bug reports which include steps to reproduce will get attention first.
|
||||
If you think you have found a bug, please [file a bug report](https://github.com/datastax/nosqlbench-labs/issues/new?labels=bug). nosqlbench is actively used within DataStax, and verified bugs will get attention as resources permit. Bugs reports which are more detailed, or bug reports which include steps to reproduce will get attention first.
|
||||
|
||||
## Feature Requests
|
||||
|
||||
If you would like to see something in DSBench that is not there yet,
|
||||
If you would like to see something in nosqlbench that is not there yet,
|
||||
please [submit a feature request](https://github.com/datastax/nosqlbench-labs/issues/new?labels=feature).
|
||||
|
||||
## Documentation Requests
|
||||
@ -10,7 +10,7 @@ common issue as we uncover them.
|
||||
|
||||
## Errors while starting nosqlbench binary
|
||||
|
||||
If you get an error while trying to run the Linux DSBench binary, ensure that you have the system module installed for fuse. This module is used by the AppImage runtime that allows for a bundled binary.
|
||||
If you get an error while trying to run the Linux nosqlbench binary, ensure that you have the system module installed for fuse. This module is used by the AppImage runtime that allows for a bundled binary.
|
||||
|
||||
## Errors when running java -jar
|
||||
|
||||
@ -0,0 +1,16 @@
|
||||
---
|
||||
title: Introducing nosqlbench
|
||||
weight: 10
|
||||
---
|
||||
|
||||
# nosqlbench docs
|
||||
|
||||
Welcome to the documentation for nosqlbench. nosqlbench 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 release. We will be adding docs for more advanced users to unlock based on a how-to format.
|
||||
|
||||
We take requests! If you have specific nosqlbench topics you'd like to
|
||||
have added to this guidebook, please make a request as described under the Support Options section.
|
||||
@ -3,7 +3,7 @@ title: 01 Installing
|
||||
weight: 1
|
||||
---
|
||||
|
||||
# 1. Installing DSBench
|
||||
# 1. Installing nosqlbench
|
||||
|
||||
If you are viewing this via the guidebook, you've already completed this step and you can move on to the next section.
|
||||
|
||||
|
||||
@ -3,9 +3,9 @@ title: 02 Running
|
||||
weight: 2
|
||||
---
|
||||
|
||||
# 2. Running DSBench
|
||||
# 2. Running nosqlbench
|
||||
|
||||
Now that we have DSBench installed, we will run a simple test against a DSE cluster to establish some basic familiarity with the tool.
|
||||
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
|
||||
|
||||
@ -28,20 +28,20 @@ CREATE TABLE baselines.keyvalue (
|
||||
|
||||
Let's break down each of those command line options.
|
||||
|
||||
`start` tells DSBench to start an activity.
|
||||
`start` tells nosqlbench to start an activity.
|
||||
|
||||
`type=...` is used to specify the activity type. In this case we are using `cql`, which tells DSBench to use the DataStax Java Driver and execute CQL statements against a database.
|
||||
`type=...` is used to specify the activity type. In this case we are using `cql`, which tells nosqlbench to use the DataStax Java Driver and execute CQL statements against a database.
|
||||
|
||||
`yaml=...` is used to specify the yaml file that defines the activity.
|
||||
All activities require a yaml in which you configure things such as data bindings and CQL statements, but don't worry about those details right now.
|
||||
|
||||
In this example, we use `baselines/cql-keyvalue` which is a pre-built workload that is packaged with DSBench.
|
||||
In this example, we use `baselines/cql-keyvalue` which is a pre-built workload that is packaged with nosqlbench.
|
||||
|
||||
`tags=phase:schema` tells DSBench to run the yaml block that has the `phase:schema` defined as one of its tags.
|
||||
`tags=phase:schema` tells nosqlbench to run the yaml block that has the `phase:schema` defined as one of its tags.
|
||||
|
||||
In this example, that is the DDL portion of the `baselines/cql-keyvalue` workload.
|
||||
|
||||
`host=...` tells DSBench how to connect to your database, only one host is necessary.
|
||||
`host=...` tells nosqlbench how to connect to your database, only one host is necessary.
|
||||
|
||||
If you like, you can verify the result of this command by decribing your keyspace in cqlsh or DataStax Studio with `DESCRIBE KEYSPACE baselines`.
|
||||
|
||||
@ -49,7 +49,7 @@ If you like, you can verify the result of this command by decribing your keyspac
|
||||
|
||||
Before running a test of typical access patterns where you want to capture the results, you need to make the test more interesting than loading an empty table. For this, we use the rampup phase.
|
||||
|
||||
Before sending our test writes to the database, we will use the `stdout` activity type so we can see what DSBench is generating for CQL statements.
|
||||
Before sending our test writes to the database, we will use the `stdout` activity type so we can see what nosqlbench is generating for CQL statements.
|
||||
|
||||
Go ahead and execute the following command:
|
||||
|
||||
@ -70,7 +70,7 @@ insert into baselines.keyvalue (key, value) values (8,296173906);
|
||||
insert into baselines.keyvalue (key, value) values (9,97405552);
|
||||
```
|
||||
|
||||
One thing to know is that DSBench deterministically generates data, so the generated values will be the same from run to run.
|
||||
One thing to know is that nosqlbench deterministically generates data, so the generated values will be the same from run to run.
|
||||
|
||||
Now we are ready to write some data to our database. Go ahead and execute the following from your command line:
|
||||
|
||||
@ -140,12 +140,12 @@ We have a few new command line options here:
|
||||
|
||||
`tags=phase:main` is using a new block in our activity's yaml that contains both read and write queries.
|
||||
|
||||
`threads=50` is an important one. The default for DSBench is to run with a single thread. This is not adequate for workloads that will be running many operations, so threads is used as a way to increase concurrency on the client side.
|
||||
`threads=50` is an important one. The default for nosqlbench is to run with a single thread. This is not adequate for workloads that will be running many operations, so threads is used as a way to increase concurrency on the client side.
|
||||
|
||||
`cyclerate=5000` is used to control the operations per second that are initiated by DSBench. This command line option is the primary means to rate limit the workload and here we are running at 5000 ops/sec.
|
||||
`cyclerate=5000` is used to control the operations per second that are initiated by nosqlbench. This command line option is the primary means to rate limit the workload and here we are running at 5000 ops/sec.
|
||||
|
||||
## Now What?
|
||||
|
||||
Note in the above output, we see `Logging to logs/scenario_20190812_154431_028.log`.
|
||||
|
||||
By default DSBench records the metrics from the run in this file, we will go into detail about these metrics in the next section Viewing Results.
|
||||
By default nosqlbench records the metrics from the run in this file, we will go into detail about these metrics in the next section Viewing Results.
|
||||
|
||||
@ -5,14 +5,14 @@ weight: 3
|
||||
|
||||
# 3. Getting Results
|
||||
|
||||
Coming off of our first run with DSBench, we ran a very simple workload against our database. In that example, we saw that DSBench writes to a log file and it is in that log file where the most basic form of metrics are displayed.
|
||||
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.
|
||||
|
||||
## Log File Metrics
|
||||
|
||||
For our previous run, we saw that DSBench was writing to `logs/scenario_20190812_154431_028.log`
|
||||
For our previous run, we saw that nosqlbench was writing to `logs/scenario_20190812_154431_028.log`
|
||||
|
||||
Even when you don't configure DSBench 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 DSBench shuts down, it will flush the partial reporting interval again to the logs. This means you can always
|
||||
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
|
||||
@ -32,7 +32,7 @@ Below is a sample of the log that gives us our basic metrics. There is a lot to
|
||||
```
|
||||
|
||||
|
||||
The log contains lots of information on metrics, but this is obviously _not_ the most desirable way to consume metrics from DSBench.
|
||||
The log contains lots of information on metrics, but this is obviously _not_ the most desirable way to consume metrics from nosqlbench.
|
||||
|
||||
We recommend that you use one of these methods, according to your environment or tooling available:
|
||||
|
||||
|
||||
@ -5,7 +5,7 @@ weight: 4
|
||||
|
||||
# 4. Reading Metrics
|
||||
|
||||
A set of core metrics are provided for every workload that runs with DSBench, 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
|
||||
|
||||
@ -29,7 +29,7 @@ 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 DSBench 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
|
||||
```
|
||||
@ -38,14 +38,14 @@ TODO: talk about mix of read / writes and how that affects this metric
|
||||
|
||||
#### metric: tries
|
||||
|
||||
DSBench 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 < 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.
|
||||
```
|
||||
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
|
||||
```
|
||||
|
||||
### More Metrics
|
||||
|
||||
DSBench extends many ways to report the metrics from a run, including:
|
||||
nosqlbench extends many ways to report the metrics from a run, including:
|
||||
|
||||
- Built-in Docker Dashboard
|
||||
- Reporting to CSV
|
||||
@ -59,5 +59,5 @@ To get more information on these options, see the output of
|
||||
|
||||
### Congratulations
|
||||
|
||||
You have completed your first run with DSBench! 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! Let's head over to the Next Steps section < link > to talk about the possibilities that are now at our fingertips.
|
||||
|
||||
|
||||
@ -9,7 +9,7 @@ Now that you've run nosqlbench for the first time and seen what it does, you can
|
||||
|
||||
The sections below describe key areas that users typically customize when working with nosqlbench.
|
||||
|
||||
Everyone who uses DSBench will want to get familiar with the basics section below. This is essential reading for new and experienced testers alike.
|
||||
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
|
||||
|
||||
@ -17,7 +17,7 @@ Several canonical workloads are already baked-in to nosqlbench for immediate use
|
||||
|
||||
Recommended reading for this is:
|
||||
1. 'Built-In Workloads'
|
||||
2. 'DSBench Basics'
|
||||
2. 'nosqlbench Basics'
|
||||
|
||||
## Workload Builders
|
||||
|
||||
@ -25,7 +25,7 @@ If you want to use nosqlbench to build a tailored workload that closely emulates
|
||||
|
||||
The recommended reading for this is:
|
||||
|
||||
1. 'DSBench Basics'
|
||||
1. 'nosqlbench Basics'
|
||||
2. All of the 'Designing Workloads' section.
|
||||
3. The online examples (find the links in the Designing Workloads section.)
|
||||
|
||||
|
||||
@ -5,5 +5,5 @@ weight: 20
|
||||
|
||||
# Getting Started
|
||||
|
||||
In this Getting Started track, we will walk you through your first test run with DSBench 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.
|
||||
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,9 +1,9 @@
|
||||
---
|
||||
title: DSBench CLI Options
|
||||
title: nosqlbench CLI Options
|
||||
weight: 01
|
||||
---
|
||||
|
||||
# DSBench CLI Options
|
||||
# nosqlbench CLI Options
|
||||
|
||||
This is the same documentation you get in markdown format with the
|
||||
`nb --help` command.
|
||||
|
||||
@ -4,14 +4,14 @@ weight: 2
|
||||
---
|
||||
|
||||
# (docker-based) Grafana Metrics
|
||||
DSBench comes with a built-in helper to get you up and running quickly
|
||||
nosqlbench comes with a built-in helper to get you up and running quickly
|
||||
with client-side testing metrics.
|
||||
|
||||
:::warning
|
||||
This feature requires that you have docker running on the local system and that your user is in a group that is allowed to manage docker. Using the `--docker-metrics` command *will* attempt to manage docker on your local system.
|
||||
:::
|
||||
|
||||
To ask DSBench to stand up your metrics infrastructure using a local docker runtime, use this command line option with any other DSBench commands:
|
||||
To ask nosqlbench to stand up your metrics infrastructure using a local docker runtime, use this command line option with any other nosqlbench commands:
|
||||
|
||||
--docker-metrics
|
||||
|
||||
|
||||
@ -5,16 +5,16 @@ weight: 03
|
||||
|
||||
# Parameter Types
|
||||
|
||||
To configure an DSBench activity to do something meaningful, you have to
|
||||
provide parameters to it. This can occur in one of several ways. This section is a guide on DSBench parameters, how they layer together, and when to use one form over another.
|
||||
To configure an nosqlbench activity to do something meaningful, you have to
|
||||
provide parameters to it. This can occur in one of several ways. This section is a guide on nosqlbench parameters, how they layer together, and when to use one form over another.
|
||||
|
||||
The command line is used to configure both the overall DSBench runtime (logging, etc) as well as the individual activities and scripts. Global DSBench options can be distinguished from scenario commands and their parameters because because global options always start with a single or --double-hyphen.
|
||||
The command line is used to configure both the overall nosqlbench runtime (logging, etc) as well as the individual activities and scripts. Global nosqlbench options can be distinguished from scenario commands and their parameters because because global options always start with a single or --double-hyphen.
|
||||
|
||||
## Activity Parameters
|
||||
|
||||
Parameters for an activity always have the form of `<name>=<value>` on the command line. Activity parameters *must* follow a command, such as `run` or `start`, for example. Scenario commands are always single words without any leading hyphens. Every command-line argument that follows a scenario command in the form of `<name>=<value>` is a parameter to that command.
|
||||
|
||||
Activity parameters can be provided by the DSBench core runtime or they can be provided by the activity type. All of the params are usable to configure an activity together. It's not important where they are provided from so long as you know what they do for your workloads, how to configure them, and where to find the docs.
|
||||
Activity parameters can be provided by the nosqlbench core runtime or they can be provided by the activity type. All of the params are usable to configure an activity together. It's not important where they are provided from so long as you know what they do for your workloads, how to configure them, and where to find the docs.
|
||||
|
||||
*Core* Activity Parameters are those provided by the core runtime.
|
||||
They are part of the core API and used by every activity type. Core activity params include type*, *alias*, and *threads*, for example.
|
||||
@ -36,7 +36,7 @@ standard YAML, then you may use a mechanism called _template parameters_. These
|
||||
|
||||
Now that we've described all the parameter types, let's tie them together. When an activity is loaded from the command line or script, the parameters are resolved in the following order:
|
||||
|
||||
1. The `type` parameter tells DSBench which activity type implementation to load.
|
||||
1. The `type` parameter tells nosqlbench which activity type implementation to load.
|
||||
2. The activity type implementation creates an activity.
|
||||
3. The activity is initialized with the parameters provided.
|
||||
4. The yaml parameter is used to load the workload definition into
|
||||
|
||||
@ -10,7 +10,7 @@ either on the command line or via a scenario script. On the command line, these
|
||||
|
||||
<paramname>=<paramvalue>
|
||||
|
||||
Some activity parameters are universal in that they can be used with any activity type. These parameters are recognized by DSBench whether or not they are recognized by a particular activity type implementation. These are called _core parameters_. Only core activity parameters are documented here.
|
||||
Some activity parameters are universal in that they can be used with any activity type. These parameters are recognized by nosqlbench whether or not they are recognized by a particular activity type implementation. These are called _core parameters_. Only core activity parameters are documented here.
|
||||
|
||||
:::info
|
||||
To see what activity parameters are valid for a given activity type, see the documentation for that activity type with `nosqlbench help <activity type>`.
|
||||
@ -25,7 +25,7 @@ To see what activity parameters are valid for a given activity type, see the doc
|
||||
|
||||
Every activity is powered by a named ActivityType. Thus, you must set the `type` parameter. If you do not specify this parameter, it will be inferred from a substring match against the alias and/or yaml parameters. If there is more than one valid match for a valid type value, then you must set the type parameter directly.
|
||||
|
||||
Telling DSBench what type of an activity will be run also determines what other parameters are considered valid and how they will be used. So in this way, the type parameter is actually the base parameter for any activity. When used with scenario commands like `run` or `start`, an activity of the named type will be initialized, and then further activity parameters on the command line will be used to configure it before it is started.
|
||||
Telling nosqlbench what type of an activity will be run also determines what other parameters are considered valid and how they will be used. So in this way, the type parameter is actually the base parameter for any activity. When used with scenario commands like `run` or `start`, an activity of the named type will be initialized, and then further activity parameters on the command line will be used to configure it before it is started.
|
||||
|
||||
## alias
|
||||
|
||||
@ -52,13 +52,13 @@ _default value_ : The name of any provided YAML filename is used as the basis fo
|
||||
|
||||
You *should* set the _threads_ parameter when you need to ramp up a workload.
|
||||
|
||||
Each activity can be created with a number of threads. It is important to adjust this setting to the system types used by DSBench.
|
||||
Each activity can be created with a number of threads. It is important to adjust this setting to the system types used by nosqlbench.
|
||||
|
||||
_default value_ : For now, the default is simply *1*. Users must be aware of
|
||||
this setting and adjust it to a reasonable value for their workloads.
|
||||
|
||||
:::info
|
||||
The threads parameter will work slightly differently for activities using the async parameter. For example, when `async=500` is provided, then the number of async operations is split between all configured threads, and each thread will juggle a number of in-flight operations asynchronously. Without the async parameter, threads determines the logical concurrency level of DSBench in the classic 'request-per-thread' mode. Neither mode is strictly correct, and both modes can be used for more accurate testing depending on the constraints of your environment.
|
||||
The threads parameter will work slightly differently for activities using the async parameter. For example, when `async=500` is provided, then the number of async operations is split between all configured threads, and each thread will juggle a number of in-flight operations asynchronously. Without the async parameter, threads determines the logical concurrency level of nosqlbench in the classic 'request-per-thread' mode. Neither mode is strictly correct, and both modes can be used for more accurate testing depending on the constraints of your environment.
|
||||
:::
|
||||
|
||||
A good rule of thumb for setting threads for maximum effect is to set it relatively high, such as 10XvCPU when running synchronous workloads (when not providing the async parameter), and to 5XvCPU for all async workloads. Variation in system dynamics make it difficult to peg an ideal number, so experimentation is encouraged while you dial in your settings initially.
|
||||
@ -85,7 +85,7 @@ In the `cycles=<cycle count>` version, the count indicates the total number of c
|
||||
- _required_: no
|
||||
- _dynamic_: no
|
||||
|
||||
Usually, you don't want to provide a setting for stride, but it is still important to understand what it does. Within DSBench, each time a thread needs to allocate a set of cycles to operate on, it takes a contiguous range of values from a shared atomic value. Thus, the stride is the unit of micro-batching within DSBench. It also means that you can use stride to optimize a workload by setting the value higher than the default. For example if you are running a single-statement workload at a very high rate, it doesn't make sense for threads to allocate one op at a time from a shared atomic value. You can simply set `stride=1000` to cause (ballpark estimation) about 1000X less internal contention.
|
||||
Usually, you don't want to provide a setting for stride, but it is still important to understand what it does. Within nosqlbench, each time a thread needs to allocate a set of cycles to operate on, it takes a contiguous range of values from a shared atomic value. Thus, the stride is the unit of micro-batching within nosqlbench. It also means that you can use stride to optimize a workload by setting the value higher than the default. For example if you are running a single-statement workload at a very high rate, it doesn't make sense for threads to allocate one op at a time from a shared atomic value. You can simply set `stride=1000` to cause (ballpark estimation) about 1000X less internal contention.
|
||||
|
||||
The stride is initialized to the calculated sequence length. The sequence length is simply the number of operations in the op sequence that is planned from your active statements and their ratios.
|
||||
|
||||
@ -136,7 +136,7 @@ This is only an optional part of the cyclerate as shown in examples above. If yo
|
||||
_default_: `1.1`
|
||||
_dynamic_: yes
|
||||
|
||||
The DSBench rate limiter provides a sliding scale between strict rate limiting and average rate limiting. The difference between them is controlled by a _burst ratio_ parameter. When the burst ratio is 1.0 (burst up to 100% relative rate), the rate limiter acts as a strict rate limiter, disallowing faster operations from using time that was previously forfeited by prior slower operations. This is a "use it or lose it" mode that means things like GC events can steal throughput from a running client as a necessary effect of losing time in a strict timing sense.
|
||||
The nosqlbench rate limiter provides a sliding scale between strict rate limiting and average rate limiting. The difference between them is controlled by a _burst ratio_ parameter. When the burst ratio is 1.0 (burst up to 100% relative rate), the rate limiter acts as a strict rate limiter, disallowing faster operations from using time that was previously forfeited by prior slower operations. This is a "use it or lose it" mode that means things like GC events can steal throughput from a running client as a necessary effect of losing time in a strict timing sense.
|
||||
|
||||
When the burst ratio is set to higher than 1.0, faster operations may recover lost time from previously slower operations. For example, a burst ratio of 1.3 means that the rate limiter will allow bursting up to 130% of the base rate, but only until the average rate is back to 100% relative speed. This means that any valleys created in the actual op rate of the client can be converted into plateaus of throughput above the strict rate, but only at a speed that fits within (op rate * burst ratio). This allows for workloads to approximate the average target rate over time, with controllable bursting rates. This ability allows for near-strict behavior while allowing clients to still track truer to rate limit expectations, so long as the overall workload is not saturating resources.
|
||||
|
||||
@ -154,7 +154,7 @@ The default burst ratio of 1.1 makes testing results slightly more stable on ave
|
||||
|
||||
The `striderate` parameter allows you to limit the start of a stride according to some rate. This works almost exactly like the cyclerate parameter, except that it blocks a whole group of operations from starting instead of a single operation. The striderate can use a burst ratio just as the cyclerate.
|
||||
|
||||
This sets the target rate for strides. In DSBench, a stride is a group of
|
||||
This sets the target rate for strides. In nosqlbench, a stride is a group of
|
||||
operations that are dispatched and executed together within the same thread.
|
||||
This is useful, for example, to emulate application behaviors in which some
|
||||
outside request translates to multiple internal requests. It is also a way
|
||||
|
||||
@ -5,7 +5,7 @@ weight: 06
|
||||
|
||||
# Core Statement Parameters
|
||||
|
||||
Some statement parameters are recognized by the DSBench runtime and can be used on any statement in a YAML file.
|
||||
Some statement parameters are recognized by the nosqlbench runtime and can be used on any statement in a YAML file.
|
||||
|
||||
## *ratio*
|
||||
|
||||
|
||||
@ -1,8 +1,8 @@
|
||||
---
|
||||
title: DSBench Basics
|
||||
title: nosqlbench Basics
|
||||
weight: 30
|
||||
---
|
||||
|
||||
This section covers the essential details that you'll need to
|
||||
run DSBench in different ways.
|
||||
run nosqlbench in different ways.
|
||||
|
||||
|
||||
@ -13,7 +13,7 @@ built-in workloads. It is strongly advised that new workload YAMLs use the same
|
||||
|
||||
### Schema phase
|
||||
|
||||
The schema phase is simply a phase of your test which creates the necessary schema on your target system. For CQL, this generally consists of a keyspace and one ore more table statements. There is no special schema layer in DSBench. All statements executed are simply statements. This provides the greatest flexibility in testing since every activity type is allowed to control its DDL and DML using the same machinery.
|
||||
The schema phase is simply a phase of your test which creates the necessary schema on your target system. For CQL, this generally consists of a keyspace and one ore more table statements. There is no special schema layer in nosqlbench. All statements executed are simply statements. This provides the greatest flexibility in testing since every activity type is allowed to control its DDL and DML using the same machinery.
|
||||
|
||||
The schema phase is normally executed with defaults for most parameters. This means that statements will execute in the order specified in the YAML, in serialized form, exactly once. This is a welcome side-effect of how the initial parameters like _cycles_ is set from the statements which are activated by tagging.
|
||||
|
||||
@ -37,7 +37,7 @@ You can mark statements as rampup phase statements by adding this set of tags to
|
||||
|
||||
### Main phase
|
||||
|
||||
The main phase of a DSBench scenario is the one during which you really care about the metric. This is the actual test that everything else has prepared your system for.
|
||||
The main phase of a nosqlbench scenario is the one during which you really care about the metric. This is the actual test that everything else has prepared your system for.
|
||||
|
||||
You can mark statement as schema phase statements by adding this set of tags to the statements, either directly, or by block:
|
||||
|
||||
|
||||
@ -5,7 +5,7 @@ weight: 02
|
||||
|
||||
## Data Bindings
|
||||
|
||||
Procedural data generation is built-in to the DSBench runtime by way of the [Virtual DataSet](http://virtdata.io/) library. This allows us to create named data generation recipes. These named recipes for generated data are called bindings. Procedural generation for test data has [many benefits](http://docs.virtdata.io/why_virtdata/why_virtdata/) over shipping bulk test data around, including speed and deterministic behavior. With the VirtData approach, most of the hard work is already done for us. We just have to pull in the recipes we want.
|
||||
Procedural data generation is built-in to the nosqlbench runtime by way of the [Virtual DataSet](http://virtdata.io/) library. This allows us to create named data generation recipes. These named recipes for generated data are called bindings. Procedural generation for test data has [many benefits](http://docs.virtdata.io/why_virtdata/why_virtdata/) over shipping bulk test data around, including speed and deterministic behavior. With the VirtData approach, most of the hard work is already done for us. We just have to pull in the recipes we want.
|
||||
|
||||
You can add a bindings section like this:
|
||||
|
||||
@ -30,7 +30,7 @@ The above bindings block is also a valid activity YAML, at least for the _stdout
|
||||
delta: WeightedStrings('one:1;six:6;three:3;')
|
||||
# EOF (control-D in your terminal)
|
||||
|
||||
[test]$ nosqlbench run type=stdout yaml=stdout-test cycles=10
|
||||
[test]$ ./nb run type=stdout yaml=stdout-test cycles=10
|
||||
0,zero,00A_pro,six
|
||||
1,one,00B_pro,six
|
||||
2,two,00C_pro,three
|
||||
@ -45,7 +45,7 @@ The above bindings block is also a valid activity YAML, at least for the _stdout
|
||||
|
||||
Above, you can see that the stdout activity type is idea for experimenting with data generation recipes. It uses the default `format=csv` parameter above, but it also supports formats like json, inlinejson, readout, and assignments.
|
||||
|
||||
This is all you need to provide a formulaic recipe for converting an ordinal value to a set of field values. Each time DSBench needs to create a set of values as parameters to a statement, the functions are called with an input, known as the cycle. The functions produce a set of named values that, when combined with a statement template, can yield an individual statement for a database operation. In this way, each cycle represents a specific operation. Since the functions above are pure functions, the cycle number of an operation will always produce the same operation, thus making all DSBench workloads deterministic.
|
||||
This is all you need to provide a formulaic recipe for converting an ordinal value to a set of field values. Each time nosqlbench needs to create a set of values as parameters to a statement, the functions are called with an input, known as the cycle. The functions produce a set of named values that, when combined with a statement template, can yield an individual statement for a database operation. In this way, each cycle represents a specific operation. Since the functions above are pure functions, the cycle number of an operation will always produce the same operation, thus making all nosqlbench workloads deterministic.
|
||||
|
||||
In the example above, you can see the cycle numbers down the left.
|
||||
|
||||
@ -66,7 +66,7 @@ bindings:
|
||||
delta: WeightedStrings('one:1;six:6;three:3;')
|
||||
# EOF (control-D in your terminal)
|
||||
|
||||
[test]$ nosqlbench run type=stdout yaml=stdout-test cycles=10
|
||||
[test]$ ./nb run type=stdout yaml=stdout-test cycles=10
|
||||
This is a statement, and the file format doesn't
|
||||
know how statements will be used!
|
||||
submit job 1 on queue one with options 00B_pro;
|
||||
|
||||
@ -40,39 +40,39 @@ statements:
|
||||
# EOF (control-D in your terminal)
|
||||
|
||||
# no tag filter matches any
|
||||
[test]$ nosqlbench run type=stdout yaml=stdout-test
|
||||
[test]$ ./nb run type=stdout yaml=stdout-test
|
||||
I'm alive!
|
||||
|
||||
# tag name assertion matches
|
||||
[test]$ nosqlbench run type=stdout yaml=stdout-test tags=name
|
||||
[test]$ ./nb run type=stdout yaml=stdout-test tags=name
|
||||
I'm alive!
|
||||
|
||||
# tag name assertion does not match
|
||||
[test]$ nosqlbench run type=stdout yaml=stdout-test tags=name2
|
||||
[test]$ ./nb run type=stdout yaml=stdout-test tags=name2
|
||||
02:25:28.158 [scenarios:001] ERROR i.e.activities.stdout.StdoutActivity - Unable to create a stdout statement if you have no active statements or bindings configured.
|
||||
|
||||
# tag value assertion does not match
|
||||
[test]$ nosqlbench run type=stdout yaml=stdout-test tags=name:bravo
|
||||
[test]$ ./nb run type=stdout yaml=stdout-test tags=name:bravo
|
||||
02:25:42.584 [scenarios:001] ERROR i.e.activities.stdout.StdoutActivity - Unable to create a stdout statement if you have no active statements or bindings configured.
|
||||
|
||||
# tag value assertion matches
|
||||
[test]$ nosqlbench run type=stdout yaml=stdout-test tags=name:foxtrot
|
||||
[test]$ ./nb run type=stdout yaml=stdout-test tags=name:foxtrot
|
||||
I'm alive!
|
||||
|
||||
# tag pattern assertion matches
|
||||
[test]$ nosqlbench run type=stdout yaml=stdout-test tags=name:'fox.*'
|
||||
[test]$ ./nb run type=stdout yaml=stdout-test tags=name:'fox.*'
|
||||
I'm alive!
|
||||
|
||||
# tag pattern assertion does not match
|
||||
[test]$ nosqlbench run type=stdout yaml=stdout-test tags=name:'tango.*'
|
||||
[test]$ ./nb run type=stdout yaml=stdout-test tags=name:'tango.*'
|
||||
02:26:05.149 [scenarios:001] ERROR i.e.activities.stdout.StdoutActivity - Unable to create a stdout statement if you have no active statements or bindings configured.
|
||||
|
||||
# compound tag predicate matches every assertion
|
||||
[test]$ nosqlbench run type=stdout yaml=stdout-test tags='name=fox.*',unit=bravo
|
||||
[test]$ ./nb run type=stdout yaml=stdout-test tags='name=fox.*',unit=bravo
|
||||
I'm alive!
|
||||
|
||||
# compound tag predicate does not fully match
|
||||
[test]$ nosqlbench run type=stdout yaml=stdout-test tags='name=fox.*',unit=delta
|
||||
[test]$ ./nb run type=stdout yaml=stdout-test tags='name=fox.*',unit=delta
|
||||
11:02:53.490 [scenarios:001] ERROR i.e.activities.stdout.StdoutActivity - Unable to create a stdout statement if you have no active statements or bindings configured.
|
||||
|
||||
|
||||
|
||||
@ -25,7 +25,7 @@ blocks:
|
||||
beta: Combinations('b;l;o;c;k;2;-;COMBINATIONS;')
|
||||
# EOF (control-D in your terminal)
|
||||
|
||||
[test]$ nosqlbench run type=stdout yaml=stdout-test cycles=10
|
||||
[test]$ ./nb run type=stdout yaml=stdout-test cycles=10
|
||||
0,block1-C
|
||||
1,block2-O
|
||||
2,block1-M
|
||||
|
||||
@ -113,5 +113,5 @@ statements:
|
||||
|
||||
Specifically, the first statement is a simple statement body, the second is a named statement (via free param `<name>: statement` form), the third is a statement config map, and the fourth is a combination of the previous two.
|
||||
|
||||
The above is valid DSBench YAML, although a reader would need
|
||||
The above is valid nosqlbench YAML, although a reader would need
|
||||
to know about the rules explained above in order to really make sense of it. For most cases, it is best to follow one format convention, but there is flexibility for overrides and naming when you need it.
|
||||
|
||||
@ -29,7 +29,7 @@ bindings:
|
||||
statements:
|
||||
- "doc2.number {numname}\n"
|
||||
# EOF (control-D in your terminal)
|
||||
[test]$ nosqlbench run type=stdout yaml=stdout-test cycles=10
|
||||
[test]$ ./nb run type=stdout yaml=stdout-test cycles=10
|
||||
doc1.form1 doc1.1
|
||||
doc1.form2 doc1.2
|
||||
doc2.number two
|
||||
|
||||
@ -5,7 +5,7 @@ weight: 08
|
||||
|
||||
# Template Params
|
||||
|
||||
All DSBench YAML formats support a parameter macro format that applies before YAML processing starts. It is a basic macro facility that allows named anchors to be placed in the document as a whole:
|
||||
All nosqlbench YAML formats support a parameter macro format that applies before YAML processing starts. It is a basic macro facility that allows named anchors to be placed in the document as a whole:
|
||||
|
||||
```text
|
||||
<<varname:defaultval>>
|
||||
@ -21,10 +21,10 @@ statements:
|
||||
- "<<linetoprint:MISSING>>\n"
|
||||
# EOF (control-D in your terminal)
|
||||
|
||||
[test]$ nosqlbench run type=stdout yaml=stdout-test cycles=1
|
||||
[test]$ ./nb run type=stdout yaml=stdout-test cycles=1
|
||||
MISSING
|
||||
|
||||
[test]$ nosqlbench run type=stdout yaml=stdout-test cycles=1 linetoprint="THIS IS IT"
|
||||
[test]$ ./nb run type=stdout yaml=stdout-test cycles=1 linetoprint="THIS IS IT"
|
||||
THIS IS IT
|
||||
```
|
||||
|
||||
|
||||
@ -5,27 +5,27 @@ weight: 40
|
||||
|
||||
# Designing Workloads
|
||||
|
||||
Workloads in DSBench are always controlled by a workload definition. Even the built-in workloads are simply pre-configured and controlled from a single YAML file which is bundled internally.
|
||||
Workloads in nosqlbench are always controlled by a workload definition. Even the built-in workloads are simply pre-configured and controlled from a single YAML file which is bundled internally.
|
||||
|
||||
With DSBench a standard YAML configuration format is provided that is used across all activity types. This makes it easy to specify statements, statement parameters, data bindings, and tags. This section describes the standard YAML format and how to use it.
|
||||
With nosqlbench a standard YAML configuration format is provided that is used across all activity types. This makes it easy to specify statements, statement parameters, data bindings, and tags. This section describes the standard YAML format and how to use it.
|
||||
|
||||
It is recommended that you read through the examples in each of the design sections in order. This guide was designed to give you a detailed understanding of workload construction with DSBench. The examples will also give you better insight into how DSBench works at a fundamental level.
|
||||
It is recommended that you read through the examples in each of the design sections in order. This guide was designed to give you a detailed understanding of workload construction with nosqlbench. The examples will also give you better insight into how nosqlbench works at a fundamental level.
|
||||
|
||||
## Multi-Protocol Support
|
||||
|
||||
You will notice that this guide is not overly CQL-specific. That is because DSBench is a multi-protocol tool. All that is needed for you to use this guide with other protocols is the release of more activity types. Try to keep that in mind as you think about designing workloads.
|
||||
You will notice that this guide is not overly CQL-specific. That is because nosqlbench is a multi-protocol tool. All that is needed for you to use this guide with other protocols is the release of more activity types. Try to keep that in mind as you think about designing workloads.
|
||||
|
||||
## Advice for new builders
|
||||
|
||||
### Review existing examples
|
||||
|
||||
The built-in workloads that are include with DSBench are also shared on the github site where we manage the DSBench project:
|
||||
The built-in workloads that are include with nosqlbench are also shared on the github site where we manage the nosqlbench project:
|
||||
|
||||
- [baselines](https://github.com/datastax/nosqlbench-labs/tree/master/sample-activities/baselines)
|
||||
- [bindings](https://github.com/datastax/nosqlbench-labs/tree/master/sample-activities/bindings)
|
||||
|
||||
### Follow the conventions
|
||||
|
||||
The tagging conventions described under the YAML Conventions section will make your testing go smoother. All of the baselines that we publish for DSBench will use this form.
|
||||
The tagging conventions described under the YAML Conventions section will make your testing go smoother. All of the baselines that we publish for nosqlbench will use this form.
|
||||
|
||||
|
||||
|
||||
@ -3,7 +3,7 @@ title: Activity Types
|
||||
weight: 50
|
||||
---
|
||||
|
||||
Each DSBench scenario is comprised of one or more activities of a specific type. The types of activities available are provided by the version of DSBench.
|
||||
Each nosqlbench scenario is comprised of one or more activities of a specific type. The types of activities available are provided by the version of nosqlbench.
|
||||
|
||||
Additional activity types will be added in future releases. This section is a reference section that shows the help you would get with a command like:
|
||||
|
||||
|
||||
@ -10,14 +10,14 @@ The EngineBlock runtime is a combination of a scripting sandbox and a workload e
|
||||
|
||||
## Machinery, Controls & Instruments
|
||||
|
||||
All of the heavy lifting is left to Java and the core DSBench runtime. This includes the iterative workloads that are meant to test the target system. This is combined with a control layer which is provided by Nashorn and eventually GraalVM. This division of responsibility allows the high-level test logic to be "script" and the low-level activity logic to be "machinery". While the scenario script has the most control, it also is the least busy relative to activity workloads. The net effect is that you have the efficiency of the iterative test loads in conjunction with the open design palette of a first-class scripting language.
|
||||
All of the heavy lifting is left to Java and the core nosqlbench runtime. This includes the iterative workloads that are meant to test the target system. This is combined with a control layer which is provided by Nashorn and eventually GraalVM. This division of responsibility allows the high-level test logic to be "script" and the low-level activity logic to be "machinery". While the scenario script has the most control, it also is the least busy relative to activity workloads. The net effect is that you have the efficiency of the iterative test loads in conjunction with the open design palette of a first-class scripting language.
|
||||
|
||||
Essentially, the ActivityType drivers are meant to handle the workload-specific machinery. They also provide dynamic control points and parameters which special to that activity type. This exposes a full feedback loop between a running scenario script and the activities that it runs. The scenario is free to read the performance metrics from a running activity and make changes to it on the fly.
|
||||
|
||||
## Scripting Environment
|
||||
|
||||
The DSBench scripting environment provided has a few
|
||||
modifications meant to streamline understanding and usage of DSBench dynamic parameters and metric.
|
||||
The nosqlbench scripting environment provided has a few
|
||||
modifications meant to streamline understanding and usage of nosqlbench dynamic parameters and metric.
|
||||
|
||||
### Active Bindings
|
||||
|
||||
@ -40,7 +40,7 @@ Each activity metric for a given activity alias is available at this name.
|
||||
This gives you access to the metrics objects directly. Some metrics objects
|
||||
have also been enhanced with wrapper logic to provide simple getters and setters, like `.p99ms` or `.p99ns`, for example.
|
||||
|
||||
Interaction with the DSBench runtime and the activities therein is made easy
|
||||
Interaction with the nosqlbench runtime and the activities therein is made easy
|
||||
by the above variables and objects. When an assignment is made to any of these variables, the changes are propagated to internal listeners. For changes to _threads_, the thread pool responsible for the affected activity adjusts the number of active threads (AKA slots). Other changes are further propagated directly to the thread harnesses and components which implement the ActivityType.
|
||||
|
||||
:::warning
|
||||
@ -52,7 +52,7 @@ mixing then with the runtime controls provided above.
|
||||
|
||||
## Enhanced Metrics for Scripting
|
||||
|
||||
The metrics available in DSBench are slightly different than the standard
|
||||
The metrics available in nosqlbench are slightly different than the standard
|
||||
kit with dropwizard metrics. The key differences are:
|
||||
|
||||
### HDR Histograms
|
||||
@ -80,7 +80,7 @@ When a script is run, it has absolute control over the scenario runtime while it
|
||||
|
||||
## Strategies
|
||||
|
||||
You can use DSBench in the classic form with `run type=<type> param=value ...` command line syntax. There are reasons, however, that you will sometimes want customize and modify your scripts directly, such as:
|
||||
You can use nosqlbench in the classic form with `run type=<type> param=value ...` command line syntax. There are reasons, however, that you will sometimes want customize and modify your scripts directly, such as:
|
||||
|
||||
- Permute test variables to cover many sub-conditions in a test.
|
||||
- Automatically adjust load factors to identify the nominal capacity of a system.
|
||||
|
||||
@ -4,21 +4,21 @@ title: Standard Metrics
|
||||
|
||||
# Standard Metrics
|
||||
|
||||
DSBench comes with a set of standard metrics that will be part of every activity type. Each activity type enhances the metrics available by adding their own metrics with the DSBench APIs. This section explains what the standard metrics are, and how to interpret them.
|
||||
nosqlbench comes with a set of standard metrics that will be part of every activity type. Each activity type enhances the metrics available by adding their own metrics with the nosqlbench APIs. This section explains what the standard metrics are, and how to interpret them.
|
||||
|
||||
## read-input
|
||||
|
||||
Within DSBench, a data stream provider called an _Input_ is responsible for providing the actual cycle number that will be used by consumer threads. Because different _Input_ implementations may perform differently, a separate metric is provided to track the performance in terms of client-side overhead. The **read-input** metric is a timer that only measured the time it takes for a given activity thread to read the input value, nothing more.
|
||||
Within nosqlbench, a data stream provider called an _Input_ is responsible for providing the actual cycle number that will be used by consumer threads. Because different _Input_ implementations may perform differently, a separate metric is provided to track the performance in terms of client-side overhead. The **read-input** metric is a timer that only measured the time it takes for a given activity thread to read the input value, nothing more.
|
||||
|
||||
## strides
|
||||
|
||||
A stride represents the work-unit for a thread within DSBench. It allows a set of cycles to be logically grouped together for purposes of optimization -- or in some cases -- to simulate realistic client-side behavior over multiple operations. The stride is the number of cycles that will be allocated to each thread before it starts iterating on them.
|
||||
A stride represents the work-unit for a thread within nosqlbench. It allows a set of cycles to be logically grouped together for purposes of optimization -- or in some cases -- to simulate realistic client-side behavior over multiple operations. The stride is the number of cycles that will be allocated to each thread before it starts iterating on them.
|
||||
|
||||
The **strides** timer measures the time each stride takes, including all cycles within the stride. It starts measuring time before the cycle starts, and stops measuring after the last cycle in the stride has run.
|
||||
|
||||
## cycles
|
||||
|
||||
Within DSBench, each logical iteration of a statement is handled within a distinct cycle. A cycle represents an iteration of a workload. This corresponds to a single operation executed according to some statement definition.
|
||||
Within nosqlbench, each logical iteration of a statement is handled within a distinct cycle. A cycle represents an iteration of a workload. This corresponds to a single operation executed according to some statement definition.
|
||||
|
||||
The **cycles** metric is a timer that starts counting at the start of a cycle, before any specific activity behavior has control. It stops timing once the logical cycle is complete. This includes and additional phases that are executed by multi-phase actions.
|
||||
|
||||
|
||||
@ -5,17 +5,17 @@ title: Timing Terms
|
||||
# Timing Terms
|
||||
|
||||
Often, terms used to describe latency can create confusion.
|
||||
In fact, the term _latency_ is so overloaded in practice that it is not useful by itself. Because of this, DSBench will avoid using the term latency _except in a specific way_. Instead, the terms described in this section will be used.
|
||||
In fact, the term _latency_ is so overloaded in practice that it is not useful by itself. Because of this, nosqlbench will avoid using the term latency _except in a specific way_. Instead, the terms described in this section will be used.
|
||||
|
||||
DSBench is a client-centric testing tool. The measurement of operations occurs on the client, without visibility to what happens in transport or on the server. This means that the client *can* see how long an operation takes, but it *cannot see* how much of the operational time is spent in transport and otherwise. This has a bearing on the terms that are adopted with DSBench.
|
||||
nosqlbench is a client-centric testing tool. The measurement of operations occurs on the client, without visibility to what happens in transport or on the server. This means that the client *can* see how long an operation takes, but it *cannot see* how much of the operational time is spent in transport and otherwise. This has a bearing on the terms that are adopted with nosqlbench.
|
||||
|
||||
Some terms are anchored by the context in which they are used. For latency terms, *service time* can be subjective. When using this term to describe other effects in your system, what is included depends on the perspective of the requester. The concept of service is universal, and every layer in a system can be seen as a service. Thus, the service time is defined by the vantage point of the requester. This is the perspective taken by the DSBench approach for naming and semantics below.
|
||||
Some terms are anchored by the context in which they are used. For latency terms, *service time* can be subjective. When using this term to describe other effects in your system, what is included depends on the perspective of the requester. The concept of service is universal, and every layer in a system can be seen as a service. Thus, the service time is defined by the vantage point of the requester. This is the perspective taken by the nosqlbench approach for naming and semantics below.
|
||||
|
||||
## responsetime
|
||||
|
||||
**The duration of time a user has to wait for a response from the time they submitted the request.** Response time is the duration of time from when a request was expected to start, to the time at which the response is finally seen by the user. A request is generally expected to start immediately when users make a request. For example, when a user enters a URL into a browser, they expect the request to start immediately when they hit enter.
|
||||
|
||||
In DSBench, the response time for any operation can be calculated by adding its wait time and its the service time together.
|
||||
In nosqlbench, the response time for any operation can be calculated by adding its wait time and its the service time together.
|
||||
|
||||
## waittime
|
||||
|
||||
@ -25,5 +25,5 @@ Wait time can accumulate when you are running something according to a dispatch
|
||||
|
||||
## servicetime
|
||||
|
||||
**The duration of time it takes a server or other system to fully process to a request and send a response.** From the perspective of a testing client, the _system_ includes the infrastructure as well as remote servers. As such, the service time metrics in DSBench include any operational time that is external to the client, including transport latency.
|
||||
**The duration of time it takes a server or other system to fully process to a request and send a response.** From the perspective of a testing client, the _system_ includes the infrastructure as well as remote servers. As such, the service time metrics in nosqlbench include any operational time that is external to the client, including transport latency.
|
||||
|
||||
|
||||
@ -25,7 +25,7 @@ With the exception of the `--docker-metrics` approach, these forms may be combin
|
||||
|
||||
If you like to have all of your testing data in one place, then you may be
|
||||
interested in reporting your measurements to a monitoring system. For this,
|
||||
DSBench includes a [Metrics Library](https://github.com/dropwizard/metrics).
|
||||
nosqlbench includes a [Metrics Library](https://github.com/dropwizard/metrics).
|
||||
Graphite reporting is baked in as the default reporter.
|
||||
|
||||
In order to enable graphite reporting, use one of these options formats:
|
||||
|
||||
@ -3,4 +3,4 @@ title: Reference
|
||||
weight: 90
|
||||
---
|
||||
|
||||
This section contains additional reference details across a range of DSBench topics.
|
||||
This section contains additional reference details across a range of nosqlbench topics.
|
||||
Loading…
Reference in New Issue
Block a user