Repository files navigation

Introduction

LaBench (for LAtency BENCHmark) is a tool that measures latency percentiles of HTTP GET or POST requests under very even and steady load.

The main feature and distinction of this tool is that (unlike many other benchmarking tools) it dictates request rate to the server and tries to maintain that rate very evenly even when server is experiencing slowdowns and hiccups. While other tools would usually back off and let the server to recover (see Coordinated Omission Problem for more details).

The main difference from wrk2 tool is very even load generated by LaBench.

Quick-Start Guide

  1. Copy or compile LaBench binary (there are both Windows and Linux executables). Windows version has more precise clock.
  2. Modify labench.yaml to meet your needs, most basic params should be self-explanatory. For the full list of supported parameters look at full_config.yaml.
  3. Run the benchmark by simply running labench (you can also specify .yaml file on command line, but labench.yaml is used by default).
  4. BEFORE looking at the latency results check the following things in the tool output:
    1. TimelyTicks percentage. If it's less than say 99.9% then you need to increase number of Clients in yaml config. It's very realistic to keep it at 100%.
    2. TimelySends percentage. If it's less than say 99.9% then you need a beefier machine to run the test. It's very realistic to keep it at 100%.
    3. Number of errors returned by the server (non-200 responses). Some small percentage is OK, but they are not accounted for in latency results.
    4. Throughput reported in last line. If should be close to the value RequestRatePerSec in your .yaml config.
  5. If ANY of the above is not satisfied then the run was not valid and there is no point in looking at the latency results produced, so fix and re-run.
  6. The measurement results (latency percentiles) are placed in out\res.hgrm file. You can open it in Excel or go to http://hdrhistogram.github.io/HdrHistogram/plotFiles.html to plot it.
  7. Note that plotted results have logarithmic X axis (i.e. the distance between 99% and 99.9% is the same as the distance between 99.9% and 99.99%).

Contributing

This project welcomes contributions and suggestions. Most contributions require you to agree to a Contributor License Agreement (CLA) declaring that you have the right to, and actually do, grant us the rights to use your contribution. For details, visit https://cla.microsoft.com.

When you submit a pull request, a CLA-bot will automatically determine whether you need to provide a CLA and decorate the PR appropriately (e.g., label, comment). Simply follow the instructions provided by the bot. You will only need to do this once across all repos using our CLA.

This project has adopted the Microsoft Open Source Code of Conduct. For more information see the Code of Conduct FAQ or contact opencode@microsoft.com with any additional questions or comments.

About

Latency Benchmarking tool

Topics

Resources

Code of conduct

Security policy

Stars

94 stars

Watchers

5 watching

Forks

Releases

Packages

Used by

Contributors

Languages

, 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Add copy buttons to all
 blocks\n(function() {\n function addCopyButtons() {\n document.querySelectorAll('pre code').forEach(function(codeBlock) {\n if (codeBlock.parentElement.hasAttribute('data-copy-added')) return;\n codeBlock.parentElement.setAttribute('data-copy-added', 'true');\n \n var btn = document.createElement('button');\n btn.textContent = 'Copy';\n btn.style.cssText = 'position:absolute;top:4px;right:4px;padding:2px 8px;font-size:11px;background:#4ecdc4;border:none;border-radius:4px;color:#1a1a2e;cursor:pointer;opacity:0.7;transition:opacity 0.2s;';\n btn.onmouseover = function() { this.style.opacity = '1'; };\n btn.onmouseout = function() { this.style.opacity = '0.7'; };\n btn.onclick = function() {\n navigator.clipboard.writeText(codeBlock.textContent).then(function() {\n btn.textContent = 'Copied!';\n setTimeout(function() { btn.textContent = 'Copy'; }, 1500);\n });\n };\n codeBlock.parentElement.style.position = 'relative';\n codeBlock.parentElement.appendChild(btn);\n });\n }\n \n addCopyButtons();\n \n // Re-run on dynamic content\n var observer = new MutationObserver(addCopyButtons);\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "Add Copy Buttons to Code Blocks");
}
} catch(__e) { console.warn('[Userscript:Add Copy Buttons to Code Blocks]', __e); }
})();
(function(){
try {
var __m = "github.com";
var __re = new RegExp('^' + "github\\.com" + '
Skip to content

Repository files navigation

Introduction

LaBench (for LAtency BENCHmark) is a tool that measures latency percentiles of HTTP GET or POST requests under very even and steady load.

The main feature and distinction of this tool is that (unlike many other benchmarking tools) it dictates request rate to the server and tries to maintain that rate very evenly even when server is experiencing slowdowns and hiccups. While other tools would usually back off and let the server to recover (see Coordinated Omission Problem for more details).

The main difference from wrk2 tool is very even load generated by LaBench.

Quick-Start Guide

  1. Copy or compile LaBench binary (there are both Windows and Linux executables). Windows version has more precise clock.
  2. Modify labench.yaml to meet your needs, most basic params should be self-explanatory. For the full list of supported parameters look at full_config.yaml.
  3. Run the benchmark by simply running labench (you can also specify .yaml file on command line, but labench.yaml is used by default).
  4. BEFORE looking at the latency results check the following things in the tool output:
    1. TimelyTicks percentage. If it's less than say 99.9% then you need to increase number of Clients in yaml config. It's very realistic to keep it at 100%.
    2. TimelySends percentage. If it's less than say 99.9% then you need a beefier machine to run the test. It's very realistic to keep it at 100%.
    3. Number of errors returned by the server (non-200 responses). Some small percentage is OK, but they are not accounted for in latency results.
    4. Throughput reported in last line. If should be close to the value RequestRatePerSec in your .yaml config.
  5. If ANY of the above is not satisfied then the run was not valid and there is no point in looking at the latency results produced, so fix and re-run.
  6. The measurement results (latency percentiles) are placed in out\res.hgrm file. You can open it in Excel or go to http://hdrhistogram.github.io/HdrHistogram/plotFiles.html to plot it.
  7. Note that plotted results have logarithmic X axis (i.e. the distance between 99% and 99.9% is the same as the distance between 99.9% and 99.99%).

Contributing

This project welcomes contributions and suggestions. Most contributions require you to agree to a Contributor License Agreement (CLA) declaring that you have the right to, and actually do, grant us the rights to use your contribution. For details, visit https://cla.microsoft.com.

When you submit a pull request, a CLA-bot will automatically determine whether you need to provide a CLA and decorate the PR appropriately (e.g., label, comment). Simply follow the instructions provided by the bot. You will only need to do this once across all repos using our CLA.

This project has adopted the Microsoft Open Source Code of Conduct. For more information see the Code of Conduct FAQ or contact opencode@microsoft.com with any additional questions or comments.

About

Latency Benchmarking tool

Topics

Resources

Code of conduct

Security policy

Stars

94 stars

Watchers

5 watching

Forks

Releases

Packages

Used by

Contributors

Languages

, 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Force GitHub README to respect dark mode\n(function() {\n var style = document.createElement('style');\n style.textContent = '\n .markdown-body {\n color-scheme: dark light;\n }\n .markdown-body pre { background: #161b22 !important; }\n .markdown-body code { background: rgba(110, 118, 129, 0.4) !important; }\n .markdown-body table th, .markdown-body table td { border-color: #30363d !important; }\n .markdown-body img { background: #0d1117; }\n .markdown-body blockquote { border-left-color: #8b949e; }\n .markdown-body hr { border-color: #30363d; }\n ';\n document.head.appendChild(style);\n})();", "GitHub Dark Mode README Fix"); } } catch(__e) { console.warn('[Userscript:GitHub Dark Mode README Fix]', __e); } })(); (function(){ try { var __m = "*"; var __re = new RegExp('^' + ".*" + '
Skip to content

Repository files navigation

Introduction

LaBench (for LAtency BENCHmark) is a tool that measures latency percentiles of HTTP GET or POST requests under very even and steady load.

The main feature and distinction of this tool is that (unlike many other benchmarking tools) it dictates request rate to the server and tries to maintain that rate very evenly even when server is experiencing slowdowns and hiccups. While other tools would usually back off and let the server to recover (see Coordinated Omission Problem for more details).

The main difference from wrk2 tool is very even load generated by LaBench.

Quick-Start Guide

  1. Copy or compile LaBench binary (there are both Windows and Linux executables). Windows version has more precise clock.
  2. Modify labench.yaml to meet your needs, most basic params should be self-explanatory. For the full list of supported parameters look at full_config.yaml.
  3. Run the benchmark by simply running labench (you can also specify .yaml file on command line, but labench.yaml is used by default).
  4. BEFORE looking at the latency results check the following things in the tool output:
    1. TimelyTicks percentage. If it's less than say 99.9% then you need to increase number of Clients in yaml config. It's very realistic to keep it at 100%.
    2. TimelySends percentage. If it's less than say 99.9% then you need a beefier machine to run the test. It's very realistic to keep it at 100%.
    3. Number of errors returned by the server (non-200 responses). Some small percentage is OK, but they are not accounted for in latency results.
    4. Throughput reported in last line. If should be close to the value RequestRatePerSec in your .yaml config.
  5. If ANY of the above is not satisfied then the run was not valid and there is no point in looking at the latency results produced, so fix and re-run.
  6. The measurement results (latency percentiles) are placed in out\res.hgrm file. You can open it in Excel or go to http://hdrhistogram.github.io/HdrHistogram/plotFiles.html to plot it.
  7. Note that plotted results have logarithmic X axis (i.e. the distance between 99% and 99.9% is the same as the distance between 99.9% and 99.99%).

Contributing

This project welcomes contributions and suggestions. Most contributions require you to agree to a Contributor License Agreement (CLA) declaring that you have the right to, and actually do, grant us the rights to use your contribution. For details, visit https://cla.microsoft.com.

When you submit a pull request, a CLA-bot will automatically determine whether you need to provide a CLA and decorate the PR appropriately (e.g., label, comment). Simply follow the instructions provided by the bot. You will only need to do this once across all repos using our CLA.

This project has adopted the Microsoft Open Source Code of Conduct. For more information see the Code of Conduct FAQ or contact opencode@microsoft.com with any additional questions or comments.

About

Latency Benchmarking tool

Topics

Resources

Code of conduct

Security policy

Stars

94 stars

Watchers

5 watching

Forks

Releases

Packages

Used by

Contributors

Languages

, 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Highlight search terms from Google/DuckDuckGo/Bing referrer\n(function() {\n var ref = document.referrer;\n var terms = [];\n \n if (ref.includes('google.com') || ref.includes('duckduckgo.com') || ref.includes('bing.com')) {\n var url = new URL(ref);\n var q = url.searchParams.get('q') || url.searchParams.get('p');\n if (q) {\n terms = q.split(/\\s+/).filter(function(t) { return t.length > 2; });\n }\n }\n \n if (terms.length === 0) return;\n \n var style = document.createElement('style');\n style.textContent = '.userscript-highlight { background: #fbbf24; color: #1a1a2e; padding: 1px 3px; border-radius: 2px; }';\n document.head.appendChild(style);\n \n function highlight(node) {\n if (node.nodeType === 3) { // text node\n var text = node.textContent;\n var found = false;\n terms.forEach(function(term) {\n var regex = new RegExp('(' + term.replace(/[.*+?^${}()|[\\]\\\\]/g, '\\\\') + ')', 'gi');\n if (regex.test(text)) {\n found = true;\n var frag = document.createDocumentFragment();\n var parts = text.split(regex);\n parts.forEach(function(part, i) {\n if (i % 2 === 0) {\n frag.appendChild(document.createTextNode(part));\n } else {\n var span = document.createElement('span');\n span.className = 'userscript-highlight';\n span.textContent = part;\n frag.appendChild(span);\n }\n });\n node.parentNode.replaceChild(frag, node);\n }\n });\n } else if (node.nodeType === 1 && node.childNodes) { // element\n var skipTags = ['SCRIPT', 'STYLE', 'NOSCRIPT', 'TEXTAREA', 'INPUT', 'SELECT'];\n if (!skipTags.includes(node.tagName)) {\n Array.from(node.childNodes).forEach(highlight);\n }\n }\n }\n \n highlight(document.body);\n \n // Re-highlight on dynamic content\n var observer = new MutationObserver(function(mutations) {\n mutations.forEach(function(m) {\n m.addedNodes.forEach(function(node) {\n if (node.nodeType === 1 || node.nodeType === 3) highlight(node);\n });\n });\n });\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "Highlight Search Terms"); } } catch(__e) { console.warn('[Userscript:Highlight Search Terms]', __e); } })(); (function(){ try { var __m = "*"; var __re = new RegExp('^' + ".*" + '
Skip to content

Repository files navigation

Introduction

LaBench (for LAtency BENCHmark) is a tool that measures latency percentiles of HTTP GET or POST requests under very even and steady load.

The main feature and distinction of this tool is that (unlike many other benchmarking tools) it dictates request rate to the server and tries to maintain that rate very evenly even when server is experiencing slowdowns and hiccups. While other tools would usually back off and let the server to recover (see Coordinated Omission Problem for more details).

The main difference from wrk2 tool is very even load generated by LaBench.

Quick-Start Guide

  1. Copy or compile LaBench binary (there are both Windows and Linux executables). Windows version has more precise clock.
  2. Modify labench.yaml to meet your needs, most basic params should be self-explanatory. For the full list of supported parameters look at full_config.yaml.
  3. Run the benchmark by simply running labench (you can also specify .yaml file on command line, but labench.yaml is used by default).
  4. BEFORE looking at the latency results check the following things in the tool output:
    1. TimelyTicks percentage. If it's less than say 99.9% then you need to increase number of Clients in yaml config. It's very realistic to keep it at 100%.
    2. TimelySends percentage. If it's less than say 99.9% then you need a beefier machine to run the test. It's very realistic to keep it at 100%.
    3. Number of errors returned by the server (non-200 responses). Some small percentage is OK, but they are not accounted for in latency results.
    4. Throughput reported in last line. If should be close to the value RequestRatePerSec in your .yaml config.
  5. If ANY of the above is not satisfied then the run was not valid and there is no point in looking at the latency results produced, so fix and re-run.
  6. The measurement results (latency percentiles) are placed in out\res.hgrm file. You can open it in Excel or go to http://hdrhistogram.github.io/HdrHistogram/plotFiles.html to plot it.
  7. Note that plotted results have logarithmic X axis (i.e. the distance between 99% and 99.9% is the same as the distance between 99.9% and 99.99%).

Contributing

This project welcomes contributions and suggestions. Most contributions require you to agree to a Contributor License Agreement (CLA) declaring that you have the right to, and actually do, grant us the rights to use your contribution. For details, visit https://cla.microsoft.com.

When you submit a pull request, a CLA-bot will automatically determine whether you need to provide a CLA and decorate the PR appropriately (e.g., label, comment). Simply follow the instructions provided by the bot. You will only need to do this once across all repos using our CLA.

This project has adopted the Microsoft Open Source Code of Conduct. For more information see the Code of Conduct FAQ or contact opencode@microsoft.com with any additional questions or comments.

About

Latency Benchmarking tool

Topics

Resources

Code of conduct

Security policy

Stars

94 stars

Watchers

5 watching

Forks

Releases

Packages

Used by

Contributors

Languages

, 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Strip utm_, fbclid, gclid, etc. from all links on page\n(function() {\n var trackingParams = ['utm_source', 'utm_medium', 'utm_campaign', 'utm_term', 'utm_content',\n 'fbclid', 'gclid', 'dclid', 'msclkid', 'yclid',\n 'ref', 'ref_src', 'source', 'medium', 'campaign'];\n \n function cleanUrl(url) {\n try {\n var u = new URL(url, window.location.origin);\n var changed = false;\n trackingParams.forEach(function(p) {\n if (u.searchParams.has(p)) {\n u.searchParams.delete(p);\n changed = true;\n }\n });\n return changed ? u.toString() : url;\n } catch (e) {\n return url;\n }\n }\n \n function cleanLinks() {\n document.querySelectorAll('a[href]').forEach(function(a) {\n var clean = cleanUrl(a.href);\n if (clean !== a.href) a.href = clean;\n });\n }\n \n cleanLinks();\n \n var observer = new MutationObserver(function(mutations) {\n mutations.forEach(function(m) {\n m.addedNodes.forEach(function(node) {\n if (node.nodeType === 1) {\n if (node.tagName === 'A') cleanLinks();\n node.querySelectorAll('a[href]').forEach(function(a) {\n var clean = cleanUrl(a.href);\n if (clean !== a.href) a.href = clean;\n });\n }\n });\n });\n });\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "Remove Tracking Parameters from Links"); } } catch(__e) { console.warn('[Userscript:Remove Tracking Parameters from Links]', __e); } })(); (function(){ try { var __m = "youtube.com"; var __re = new RegExp('^' + "youtube\\.com" + '
Skip to content

Repository files navigation

Introduction

LaBench (for LAtency BENCHmark) is a tool that measures latency percentiles of HTTP GET or POST requests under very even and steady load.

The main feature and distinction of this tool is that (unlike many other benchmarking tools) it dictates request rate to the server and tries to maintain that rate very evenly even when server is experiencing slowdowns and hiccups. While other tools would usually back off and let the server to recover (see Coordinated Omission Problem for more details).

The main difference from wrk2 tool is very even load generated by LaBench.

Quick-Start Guide

  1. Copy or compile LaBench binary (there are both Windows and Linux executables). Windows version has more precise clock.
  2. Modify labench.yaml to meet your needs, most basic params should be self-explanatory. For the full list of supported parameters look at full_config.yaml.
  3. Run the benchmark by simply running labench (you can also specify .yaml file on command line, but labench.yaml is used by default).
  4. BEFORE looking at the latency results check the following things in the tool output:
    1. TimelyTicks percentage. If it's less than say 99.9% then you need to increase number of Clients in yaml config. It's very realistic to keep it at 100%.
    2. TimelySends percentage. If it's less than say 99.9% then you need a beefier machine to run the test. It's very realistic to keep it at 100%.
    3. Number of errors returned by the server (non-200 responses). Some small percentage is OK, but they are not accounted for in latency results.
    4. Throughput reported in last line. If should be close to the value RequestRatePerSec in your .yaml config.
  5. If ANY of the above is not satisfied then the run was not valid and there is no point in looking at the latency results produced, so fix and re-run.
  6. The measurement results (latency percentiles) are placed in out\res.hgrm file. You can open it in Excel or go to http://hdrhistogram.github.io/HdrHistogram/plotFiles.html to plot it.
  7. Note that plotted results have logarithmic X axis (i.e. the distance between 99% and 99.9% is the same as the distance between 99.9% and 99.99%).

Contributing

This project welcomes contributions and suggestions. Most contributions require you to agree to a Contributor License Agreement (CLA) declaring that you have the right to, and actually do, grant us the rights to use your contribution. For details, visit https://cla.microsoft.com.

When you submit a pull request, a CLA-bot will automatically determine whether you need to provide a CLA and decorate the PR appropriately (e.g., label, comment). Simply follow the instructions provided by the bot. You will only need to do this once across all repos using our CLA.

This project has adopted the Microsoft Open Source Code of Conduct. For more information see the Code of Conduct FAQ or contact opencode@microsoft.com with any additional questions or comments.

About

Latency Benchmarking tool

Topics

Resources

Code of conduct

Security policy

Stars

94 stars

Watchers

5 watching

Forks

Releases

Packages

Used by

Contributors

Languages

, 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Auto-enable theater mode on YouTube\n(function() {\n function tryTheater() {\n var btn = document.querySelector('button[aria-label=\"Theater mode\"], ytd-player #player button[title=\"Theater mode\"]');\n if (btn && !btn.classList.contains('activated')) {\n btn.click();\n }\n }\n \n // Try immediately\n tryTheater();\n \n // Try after navigation (SPA)\n var lastUrl = location.href;\n setInterval(function() {\n if (location.href !== lastUrl) {\n lastUrl = location.href;\n setTimeout(tryTheater, 500);\n }\n }, 1000);\n \n // Also try on player load\n var observer = new MutationObserver(tryTheater);\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "YouTube Theater Mode Default"); } } catch(__e) { console.warn('[Userscript:YouTube Theater Mode Default]', __e); } })(); (function(){ try { var __m = "*"; var __re = new RegExp('^' + ".*" + '
Skip to content

Repository files navigation

Introduction

LaBench (for LAtency BENCHmark) is a tool that measures latency percentiles of HTTP GET or POST requests under very even and steady load.

The main feature and distinction of this tool is that (unlike many other benchmarking tools) it dictates request rate to the server and tries to maintain that rate very evenly even when server is experiencing slowdowns and hiccups. While other tools would usually back off and let the server to recover (see Coordinated Omission Problem for more details).

The main difference from wrk2 tool is very even load generated by LaBench.

Quick-Start Guide

  1. Copy or compile LaBench binary (there are both Windows and Linux executables). Windows version has more precise clock.
  2. Modify labench.yaml to meet your needs, most basic params should be self-explanatory. For the full list of supported parameters look at full_config.yaml.
  3. Run the benchmark by simply running labench (you can also specify .yaml file on command line, but labench.yaml is used by default).
  4. BEFORE looking at the latency results check the following things in the tool output:
    1. TimelyTicks percentage. If it's less than say 99.9% then you need to increase number of Clients in yaml config. It's very realistic to keep it at 100%.
    2. TimelySends percentage. If it's less than say 99.9% then you need a beefier machine to run the test. It's very realistic to keep it at 100%.
    3. Number of errors returned by the server (non-200 responses). Some small percentage is OK, but they are not accounted for in latency results.
    4. Throughput reported in last line. If should be close to the value RequestRatePerSec in your .yaml config.
  5. If ANY of the above is not satisfied then the run was not valid and there is no point in looking at the latency results produced, so fix and re-run.
  6. The measurement results (latency percentiles) are placed in out\res.hgrm file. You can open it in Excel or go to http://hdrhistogram.github.io/HdrHistogram/plotFiles.html to plot it.
  7. Note that plotted results have logarithmic X axis (i.e. the distance between 99% and 99.9% is the same as the distance between 99.9% and 99.99%).

Contributing

This project welcomes contributions and suggestions. Most contributions require you to agree to a Contributor License Agreement (CLA) declaring that you have the right to, and actually do, grant us the rights to use your contribution. For details, visit https://cla.microsoft.com.

When you submit a pull request, a CLA-bot will automatically determine whether you need to provide a CLA and decorate the PR appropriately (e.g., label, comment). Simply follow the instructions provided by the bot. You will only need to do this once across all repos using our CLA.

This project has adopted the Microsoft Open Source Code of Conduct. For more information see the Code of Conduct FAQ or contact opencode@microsoft.com with any additional questions or comments.

About

Latency Benchmarking tool

Topics

Resources

Code of conduct

Security policy

Stars

94 stars

Watchers

5 watching

Forks

Releases

Packages

Used by

Contributors

Languages

, 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Remove or un-stick sticky/fixed headers that block content\n(function() {\n function unstick() {\n document.querySelectorAll('header, nav, [role=\"banner\"], .header, .navbar, .sticky, .fixed-top, [style*=\"position: fixed\"], [style*=\"position:sticky\"]').forEach(function(el) {\n if (el.style.position === 'fixed' || el.style.position === 'sticky' || \n getComputedStyle(el).position === 'fixed' || getComputedStyle(el).position === 'sticky') {\n el.style.position = 'static';\n el.style.top = 'auto';\n el.style.zIndex = 'auto';\n }\n });\n }\n \n unstick();\n \n var observer = new MutationObserver(unstick);\n observer.observe(document.body, { childList: true, subtree: true, attributes: true, attributeFilter: ['style', 'class'] });\n})();", "Kill Sticky Headers"); } } catch(__e) { console.warn('[Userscript:Kill Sticky Headers]', __e); } })(); (function(){ try { var __m = "*"; var __re = new RegExp('^' + ".*" + '
Skip to content

Repository files navigation

Introduction

LaBench (for LAtency BENCHmark) is a tool that measures latency percentiles of HTTP GET or POST requests under very even and steady load.

The main feature and distinction of this tool is that (unlike many other benchmarking tools) it dictates request rate to the server and tries to maintain that rate very evenly even when server is experiencing slowdowns and hiccups. While other tools would usually back off and let the server to recover (see Coordinated Omission Problem for more details).

The main difference from wrk2 tool is very even load generated by LaBench.

Quick-Start Guide

  1. Copy or compile LaBench binary (there are both Windows and Linux executables). Windows version has more precise clock.
  2. Modify labench.yaml to meet your needs, most basic params should be self-explanatory. For the full list of supported parameters look at full_config.yaml.
  3. Run the benchmark by simply running labench (you can also specify .yaml file on command line, but labench.yaml is used by default).
  4. BEFORE looking at the latency results check the following things in the tool output:
    1. TimelyTicks percentage. If it's less than say 99.9% then you need to increase number of Clients in yaml config. It's very realistic to keep it at 100%.
    2. TimelySends percentage. If it's less than say 99.9% then you need a beefier machine to run the test. It's very realistic to keep it at 100%.
    3. Number of errors returned by the server (non-200 responses). Some small percentage is OK, but they are not accounted for in latency results.
    4. Throughput reported in last line. If should be close to the value RequestRatePerSec in your .yaml config.
  5. If ANY of the above is not satisfied then the run was not valid and there is no point in looking at the latency results produced, so fix and re-run.
  6. The measurement results (latency percentiles) are placed in out\res.hgrm file. You can open it in Excel or go to http://hdrhistogram.github.io/HdrHistogram/plotFiles.html to plot it.
  7. Note that plotted results have logarithmic X axis (i.e. the distance between 99% and 99.9% is the same as the distance between 99.9% and 99.99%).

Contributing

This project welcomes contributions and suggestions. Most contributions require you to agree to a Contributor License Agreement (CLA) declaring that you have the right to, and actually do, grant us the rights to use your contribution. For details, visit https://cla.microsoft.com.

When you submit a pull request, a CLA-bot will automatically determine whether you need to provide a CLA and decorate the PR appropriately (e.g., label, comment). Simply follow the instructions provided by the bot. You will only need to do this once across all repos using our CLA.

This project has adopted the Microsoft Open Source Code of Conduct. For more information see the Code of Conduct FAQ or contact opencode@microsoft.com with any additional questions or comments.

About

Latency Benchmarking tool

Topics

Resources

Code of conduct

Security policy

Stars

94 stars

Watchers

5 watching

Forks

Releases

Packages

Used by

Contributors

Languages

, 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Universal Dark Mode - works on any site\n(function() {\n var enabled = true;\n \n function applyDarkMode() {\n if (!enabled) return;\n \n // Create style element if it doesn't exist\n var style = document.getElementById('universal-dark-mode-style');\n if (!style) {\n style = document.createElement('style');\n style.id = 'universal-dark-mode-style';\n document.head.appendChild(style);\n }\n \n // Dark mode CSS - inverts colors but preserves images/video\n style.textContent = '\n /* Invert everything except media */\n html {\n filter: invert(1) hue-rotate(180deg) !important;\n background: #1a1a2e !important;\n }\n \n /* Restore images, videos, iframes, canvas */\n img, video, iframe, canvas, svg, picture, [style*=\"background-image\"] {\n filter: invert(1) hue-rotate(180deg) !important;\n }\n \n /* Preserve specific elements that should not be inverted */\n .no-dark-mode, .no-dark-mode *,\n [data-theme=\"light\"], [data-theme=\"light\"],\n .ace_editor, .ace_editor *,\n .CodeMirror, .CodeMirror *,\n .monaco-editor, .monaco-editor *,\n .markdown-body pre, .markdown-body pre *,\n .highlight, .highlight *,\n pre code, pre code * {\n filter: none !important;\n }\n \n /* Fix common UI elements */\n .modal, .popup, .dropdown-menu, .tooltip, .popover {\n filter: invert(1) hue-rotate(180deg) !important;\n background: #2d2d44 !important;\n border-color: #444 !important;\n }\n \n /* Scrollbars */\n ::-webkit-scrollbar { background: #1a1a2e !important; }\n ::-webkit-scrollbar-thumb { background: #444 !important; }\n ::-webkit-scrollbar-thumb:hover { background: #555 !important; }\n \n /* Selection */\n ::selection { background: #4ecdc4 !important; color: #1a1a2e !important; }\n ::-moz-selection { background: #4ecdc4 !important; color: #1a1a2e !important; }\n ';\n }\n \n function removeDarkMode() {\n var style = document.getElementById('universal-dark-mode-style');\n if (style) style.remove();\n }\n \n // Toggle with Alt+Shift+D\n document.addEventListener('keydown', function(e) {\n if (e.altKey && e.shiftKey && e.key === 'D') {\n e.preventDefault();\n enabled = !enabled;\n if (enabled) {\n applyDarkMode();\n console.log('[Universal Dark Mode] Enabled');\n } else {\n removeDarkMode();\n console.log('[Universal Dark Mode] Disabled');\n }\n }\n });\n \n // Apply on load\n applyDarkMode();\n \n // Re-apply on dynamic content\n var observer = new MutationObserver(function(mutations) {\n if (enabled && !document.getElementById('universal-dark-mode-style')) {\n applyDarkMode();\n }\n });\n observer.observe(document.head, { childList: true });\n \n console.log('[Universal Dark Mode] Loaded - Press Alt+Shift+D to toggle');\n})();", "Universal Dark Mode"); } } catch(__e) { console.warn('[Userscript:Universal Dark Mode]', __e); } })(); })();
Skip to content

Repository files navigation

Introduction

LaBench (for LAtency BENCHmark) is a tool that measures latency percentiles of HTTP GET or POST requests under very even and steady load.

The main feature and distinction of this tool is that (unlike many other benchmarking tools) it dictates request rate to the server and tries to maintain that rate very evenly even when server is experiencing slowdowns and hiccups. While other tools would usually back off and let the server to recover (see Coordinated Omission Problem for more details).

The main difference from wrk2 tool is very even load generated by LaBench.

Quick-Start Guide

  1. Copy or compile LaBench binary (there are both Windows and Linux executables). Windows version has more precise clock.
  2. Modify labench.yaml to meet your needs, most basic params should be self-explanatory. For the full list of supported parameters look at full_config.yaml.
  3. Run the benchmark by simply running labench (you can also specify .yaml file on command line, but labench.yaml is used by default).
  4. BEFORE looking at the latency results check the following things in the tool output:
    1. TimelyTicks percentage. If it's less than say 99.9% then you need to increase number of Clients in yaml config. It's very realistic to keep it at 100%.
    2. TimelySends percentage. If it's less than say 99.9% then you need a beefier machine to run the test. It's very realistic to keep it at 100%.
    3. Number of errors returned by the server (non-200 responses). Some small percentage is OK, but they are not accounted for in latency results.
    4. Throughput reported in last line. If should be close to the value RequestRatePerSec in your .yaml config.
  5. If ANY of the above is not satisfied then the run was not valid and there is no point in looking at the latency results produced, so fix and re-run.
  6. The measurement results (latency percentiles) are placed in out\res.hgrm file. You can open it in Excel or go to http://hdrhistogram.github.io/HdrHistogram/plotFiles.html to plot it.
  7. Note that plotted results have logarithmic X axis (i.e. the distance between 99% and 99.9% is the same as the distance between 99.9% and 99.99%).

Contributing

This project welcomes contributions and suggestions. Most contributions require you to agree to a Contributor License Agreement (CLA) declaring that you have the right to, and actually do, grant us the rights to use your contribution. For details, visit https://cla.microsoft.com.

When you submit a pull request, a CLA-bot will automatically determine whether you need to provide a CLA and decorate the PR appropriately (e.g., label, comment). Simply follow the instructions provided by the bot. You will only need to do this once across all repos using our CLA.

This project has adopted the Microsoft Open Source Code of Conduct. For more information see the Code of Conduct FAQ or contact opencode@microsoft.com with any additional questions or comments.

About

Latency Benchmarking tool

Topics

Resources

Code of conduct

Security policy

Stars

94 stars

Watchers

5 watching

Forks

Releases

Packages

Used by

Contributors

Languages