Add "Calculate concurrent users for load tests" guide (#1839)

* Add Calculate concurrent users for load tests guide

Based on blog post https://k6.io/blog/monthly-visits-concurrent-users/

* Reorder testing guides section

* Apply to next

* Skip code blocks

* Add skip blocks

* Apply suggestions from code review

Co-authored-by: Ivan <[email protected]>

* Add skip blocks

* Add code skip block

* Add code skip blocks

---------

Co-authored-by: Ivan <[email protected]>

docs/sources/k6/next/testing-guides/api-load-testing.md

@@ -1,9 +1,7 @@
 ---
 title: 'API load testing'
-head_title: 'Intro to API Load Testing: The k6 Guide'
 description: 'Load testing APIs has many facets. This guide introduces you to performance testing and provides best practices to load test your APIs with k6.'
-weight: 01
-noindex: true
+weight: 100
 ---
 
 # API load testing

docs/sources/k6/next/testing-guides/calculate-concurrent-users.md

@@ -0,0 +1,102 @@
+---
+title: 'Calculate concurrent users for load tests'
+description: 'Learn how to use Google Analytics data to determine the optimal number of concurrent users for your load tests.'
+weight: 200
+---
+
+# Calculate concurrent users for load tests
+
+When planning load tests, determining the right number of concurrent users is crucial for creating realistic test scenarios. This guide explains how to use Google Analytics data to calculate concurrent user numbers and design effective load tests.
+
+{{< admonition type="note" >}}
+
+You can use any analytics tool that provides the same metrics to help you calculate the concurrent users you need for load testing.
+
+{{< /admonition >}}
+
+## Understanding concurrent users
+
+Google Analytics tracks visitors ("Users") and their activity periods ("Sessions") on your site. During a session, users generate traffic through page loads or AJAX requests that your servers must handle. To create realistic load tests, you need to determine how many users are actively generating traffic at any given time.
+
+The recommended formula for calculating your baseline of hourly concurrent users is:
+
+```
+An hour in seconds = 3600
+Concurrent users  = Hourly sessions * Average session duration (in seconds) / 3600
+```
+
+## Get the data from Google Analytics
+
+To find the required metrics in Google Analytics:
+
+- Log in to your Google Analytics account.
+- Navigate to the **Reporting** tab.
+- Click **Audience** on the sidebar menu.
+- Click **Overview**.
+- Set your desired time period.
+- Click **Hourly** view in the line graph settings.
+
+You should be able to view the session count and average session duration on the overview dashboard.
+
+{{< admonition type="note" >}}
+
+These instructions might vary depending on which version of Google Analytics you're using. If you're using Google Analytics 4, you can find these metrics by selecting **Explore** and creating a **Free form** report.
+
+{{< /admonition >}}
+
+## Designing load tests
+
+With the data in hand, it's important to mention why you want to use the "Hourly" view.
+
+Using hourly metrics rather than daily or monthly averages is crucial for accurate load testing. Daily averages can mask significant traffic variations that occur throughout the day. For example, an e-commerce site might see most of its traffic during business hours, with peaks during lunch breaks. Using daily averages would underestimate these crucial peak periods.
+
+Additionally, hourly metrics help identify patterns in user behavior. A news site might see traffic spikes during morning commute hours and evening hours, while a restaurant booking service might peak during evening hours. Understanding these patterns through hourly data helps you design more realistic load tests that match your actual usage patterns.
+
+### Calculate peak traffic
+
+Instead of using average traffic levels, base your load tests on peak traffic periods:
+
+1. Identify peak hours in Google Analytics.
+1. Calculate concurrent users during these peaks.
+1. Add a margin to ensure you can handle higher traffic levels.
+
+For example, if your site averages 0.08 concurrent sessions monthly but peaks at 7.2 concurrent sessions during high-traffic hours, you should test for at least this peak level.
+
+### Example calculation
+
+As an example, for a website that has the following metrics:
+
+- 2,591 monthly sessions
+- 82 seconds per session
+
+Applying the concurrent user formula, you can find the average concurrent users:
+
+```
+2,591 monthly sessions x 82 seconds per session / 3600 = 59.0172
+
+// To convert monthly sessions to hourly sessions, you can divide the value by 720
+59.0172 / 720 (30 days in November x 24h per day = 720) = 0.08 average concurrent users in November
+```
+
+But, if the same website has peak hours from 3 PM to 4 PM with different metrics:
+
+- 990 sessions
+- 92 seconds
+
+In this case, applying the concurrent users formula leads to:
+
+```
+990 sessions x 92 seconds per session / 3600 = 25.3 average concurrent users
+```
+
+This example shows how peak traffic can reach a considerably higher value than the monthly average, in this case from 0.8 to 25.3 concurrent users, highlighting the importance of testing beyond average traffic levels.
+
+## Additional testing considerations
+
+There are multiple scenarios where a different kind of test might give you a better insights on your system reliability. Consider implementing these testing strategies:
+
+- [Spike tests](https://grafana.com/docs/k6/<K6_VERSION>/testing-guides/test-types/spike-testing/) before major events.
+- Regular load tests at peak traffic levels.
+- Tests that exceed your highest historical traffic by a safety margin.
+
+These practices help ensure your system remains stable during unexpected traffic increases. Refer to [Testing guides](https://grafana.com/docs/k6/<K6_VERSION>/testing-guides) for more details about all of the different performance testing strategies.

docs/sources/k6/next/testing-guides/injecting-faults-with-xk6-disruptor/_index.md

@@ -3,7 +3,7 @@ aliases:
   - ../javascript-api/xk6-disruptor/get-started # docs/k6/<K6_VERSION>/javascript-api/xk6-disruptor/get-started/
 title: 'Injecting faults with xk6-disruptor'
 description: 'xk6-disruptor is a k6 extension providing fault injection capabilities to test system reliability under turbulent conditions.'
-weight: 06
+weight: 800
 ---
 
 # Injecting faults with xk6-disruptor

docs/sources/k6/next/testing-guides/load-testing-websites.md

@@ -1,9 +1,7 @@
 ---
 title: 'Load testing websites'
-head_title: 'How to Load Test a Website: The k6 Guide'
 description: 'Do you know how many users your site can handle? This guide answers the WHY and WHEN you should load test your website and gives you the best practices for load testing websites or web apps with k6. Let’s get started.'
-weight: 03
-noindex: true
+weight: 300
 ---
 
 # Load testing websites
@@ -128,6 +126,8 @@ While protocol-based load testing may seem to lend itself better to component te
 
 The following is an example of a protocol-based load testing script in k6 that fetches the homepage, along with resources embedded into the page.
 
+<!-- md-k6:skip -->
+
 ```javascript
 import http from 'k6/http';
 import { sleep, check } from 'k6';
@@ -187,6 +187,7 @@ The following is an example of a browser-based load testing script in k6 using t
 
 {{< code >}}
 
+<!-- md-k6:skip -->
 <!-- eslint-skip -->
 
 ```javascript

docs/sources/k6/next/testing-guides/running-distributed-tests.md

@@ -1,7 +1,7 @@
 ---
 title: 'Running distributed tests'
 description: 'How to run distributed tests in Kubernetes'
-weight: 05
+weight: 400
 ---
 
 # Running distributed tests
@@ -324,6 +324,8 @@ The above YAML introduces the `runner` section. This section applies to each pod
 
 Now, with the referenced resources, our test scripts can [use environment variables](https://grafana.com/docs/k6/<K6_VERSION>/using-k6/environment-variables) as in the following:
 
+<!-- md-k6:skip -->
+
 ```javascript
 export function setup() {
   console.log(`Variable is set as: ${__ENV.MY_CUSTOM_VARIABLE}`);

docs/sources/k6/next/testing-guides/running-large-tests.md

@@ -1,7 +1,7 @@
 ---
 title: 'Running large tests'
 description: 'How to run large-scale k6 tests without distributed-execution'
-weight: 04
+weight: 500
 ---
 
 # Running large tests
@@ -113,6 +113,8 @@ An oversight of some scripts is to test with only the [happy path](https://grafa
 
 For example, in k6 scripts, we often see something like this _happy path_ check:
 
+<!-- md-k6:skip -->
+
 ```javascript
 import { check } from 'k6';
 import http from 'k6/http';
@@ -140,6 +142,8 @@ The following change will handle the exception.
 
 {{< code >}}
 
+<!-- md-k6:skip -->
+
 ```javascript
 import { check } from 'k6';
 import http from 'k6/http';
@@ -164,6 +168,8 @@ By default, k6 loads the response body of the request into memory. This causes m
 
 To instruct k6 to not process all response bodies, set `discardResponseBodies` in the options object like this:
 
+<!-- md-k6:skip -->
+
 ```javascript
 export const options = {
   discardResponseBodies: true,

docs/sources/k6/next/testing-guides/synthetic-monitoring.md

@@ -1,14 +1,11 @@
 ---
 title: 'Synthetic monitoring'
 description: 'Use k6 as synthetic monitoring tool, scheduling k6 smoke tests for continuous production monitoring.'
-weight: 03
-noindex: true
+weight: 600
 ---
 
 # Synthetic monitoring
 
 You can use k6 as synthetic monitoring tool by scheduling k6 smoke tests for continuous production monitoring.
 
-For a simple demo stack, see this [tutorial on using `cron` and `mail`](https://k6.io/blog/performance-monitoring-with-cron-and-k6/).
-
 For a more comprehensive solution, you can use [Grafana Cloud Synthetic Monitoring](https://grafana.com/docs/grafana-cloud/testing/synthetic-monitoring/create-checks/checks/k6/) to proactively monitor your application and services in production. You can run k6 smoke tests at frequent intervals, receive alerts on potential issues, and manage incidents directly from [Grafana Cloud](https://grafana.com/products/cloud/).

docs/sources/k6/next/testing-guides/use-chai-with-k6.md

@@ -1,7 +1,7 @@
 ---
 title: 'Use Chai with k6'
 description: 'Use Chai with k6 by using the k6chaijs library. Leverage BDD assertions to write tests that scale and are easier to maintain.'
-weight: 100
+weight: 700
 ---
 
 # Use Chai with k6

docs/sources/k6/v0.56.x/testing-guides/api-load-testing.md

@@ -1,9 +1,7 @@
 ---
 title: 'API load testing'
-head_title: 'Intro to API Load Testing: The k6 Guide'
 description: 'Load testing APIs has many facets. This guide introduces you to performance testing and provides best practices to load test your APIs with k6.'
-weight: 01
-noindex: true
+weight: 100
 ---
 
 # API load testing

docs/sources/k6/v0.56.x/testing-guides/calculate-concurrent-users.md

@@ -0,0 +1,101 @@
+---
+title: 'Calculate concurrent users for load tests'
+description: 'Learn how to use Google Analytics data to determine the optimal number of concurrent users for your load tests.'
+weight: 200
+---
+
+# Calculate concurrent users for load tests
+
+When planning load tests, determining the right number of concurrent users is crucial for creating realistic test scenarios. This guide explains how to use Google Analytics data to calculate concurrent user numbers and design effective load tests.
+
+{{< admonition type="note" >}}
+
+You can use any analytics tool that provides the same metrics to help you calculate the concurrent users you need for load testing.
+
+{{< /admonition >}}
+
+## Understanding concurrent users
+
+Google Analytics tracks visitors ("Users") and their activity periods ("Sessions") on your site. During a session, users generate traffic through page loads or AJAX requests that your servers must handle. To create realistic load tests, you need to determine how many users are actively generating traffic at any given time.
+
+The recommended formula for calculating your baseline concurrent users is:
+
+```
+Concurrent users  = Hourly sessions * Average session duration (in seconds) / 3600
+```
+
+## Get the data from Google Analytics
+
+To find the required metrics in Google Analytics:
+
+- Log in to your Google Analytics account.
+- Navigate to the **Reporting** tab.
+- Click **Audience** on the sidebar menu.
+- Click **Overview**.
+- Set your desired time period.
+- Click **Hourly** view in the line graph settings.
+
+You should be able to view the session count and average session duration on the overview dashboard.
+
+{{< admonition type="note" >}}
+
+These instructions might vary depending on which version of Google Analytics you're using. If you're using Google Analytics 4, you can find these metrics by selecting **Explore** and creating a **Free form** report.
+
+{{< /admonition >}}
+
+## Designing load tests
+
+With the data in hand, it's important to mention why you want to use the "Hourly" view.
+
+Using hourly metrics rather than daily or monthly averages is crucial for accurate load testing. Daily averages can mask significant traffic variations that occur throughout the day. For example, an e-commerce site might see most of its traffic during business hours, with peaks during lunch breaks. Using daily averages would underestimate these crucial peak periods.
+
+Additionally, hourly metrics help identify patterns in user behavior. A news site might see traffic spikes during morning commute hours and evening hours, while a restaurant booking service might peak during evening hours. Understanding these patterns through hourly data helps you design more realistic load tests that match your actual usage patterns.
+
+### Calculate peak traffic
+
+Instead of using average traffic levels, base your load tests on peak traffic periods:
+
+1. Identify peak hours in Google Analytics.
+1. Calculate concurrent users during these peaks.
+1. Add a margin to ensure you can handle higher traffic levels.
+
+For example, if your site averages 0.08 concurrent sessions monthly but peaks at 7.2 concurrent sessions during high-traffic hours, you should test for at least this peak level.
+
+### Example calculation
+
+As an example, for a website that has the following metrics:
+
+- 2,591 monthly sessions
+- 82 seconds per session
+
+Applying the concurrent user formula, you can find the average concurrent user:
+
+```
+2,591 monthly sessions x 82 seconds per session / 3600 = 59.0172
+
+// To convert monthly sessions to hourly sessions, you can divide the value by 720
+59.0172 / 720 (30 days in November x 24h per day = 720) = .08 average concurrent users in November
+```
+
+But, if the same website has peak hours from 3 PM to 4 PM with different metrics:
+
+- 990 sessions
+- 92 seconds
+
+In this case, applying the concurrent user formula leads to:
+
+```
+990 sessions x 92 seconds per session / 3600 = 25.3 concurrent users
+```
+
+This example shows how peak traffic can reach a considerably higher value than the monthly average, in this case from 0.8 to 25.3 concurrent users, highlighting the importance of testing beyond average traffic levels.
+
+## Additional testing considerations
+
+Consider implementing these testing strategies:
+
+- [Spike tests](https://grafana.com/docs/k6/<K6_VERSION>/testing-guides/test-types/spike-testing/) before major events.
+- Regular load tests at peak traffic levels.
+- Tests that exceed your highest historical traffic by a safety margin.
+
+These practices help ensure your system remains stable during unexpected traffic increases.

docs/sources/k6/v0.56.x/testing-guides/injecting-faults-with-xk6-disruptor/_index.md

@@ -3,7 +3,7 @@ aliases:
   - ../javascript-api/xk6-disruptor/get-started # docs/k6/<K6_VERSION>/javascript-api/xk6-disruptor/get-started/
 title: 'Injecting faults with xk6-disruptor'
 description: 'xk6-disruptor is a k6 extension providing fault injection capabilities to test system reliability under turbulent conditions.'
-weight: 06
+weight: 800
 ---
 
 # Injecting faults with xk6-disruptor

docs/sources/k6/v0.56.x/testing-guides/load-testing-websites.md

@@ -1,9 +1,7 @@
 ---
 title: 'Load testing websites'
-head_title: 'How to Load Test a Website: The k6 Guide'
 description: 'Do you know how many users your site can handle? This guide answers the WHY and WHEN you should load test your website and gives you the best practices for load testing websites or web apps with k6. Let’s get started.'
-weight: 03
-noindex: true
+weight: 300
 ---
 
 # Load testing websites

docs/sources/k6/v0.56.x/testing-guides/running-distributed-tests.md

@@ -1,7 +1,7 @@
 ---
 title: 'Running distributed tests'
 description: 'How to run distributed tests in Kubernetes'
-weight: 05
+weight: 400
 ---
 
 # Running distributed tests

docs/sources/k6/v0.56.x/testing-guides/running-large-tests.md

@@ -1,7 +1,7 @@
 ---
 title: 'Running large tests'
 description: 'How to run large-scale k6 tests without distributed-execution'
-weight: 04
+weight: 500
 ---
 
 # Running large tests

docs/sources/k6/v0.56.x/testing-guides/synthetic-monitoring.md

@@ -1,14 +1,11 @@
 ---
 title: 'Synthetic monitoring'
 description: 'Use k6 as synthetic monitoring tool, scheduling k6 smoke tests for continuous production monitoring.'
-weight: 03
-noindex: true
+weight: 600
 ---
 
 # Synthetic monitoring
 
 You can use k6 as synthetic monitoring tool by scheduling k6 smoke tests for continuous production monitoring.
 
-For a simple demo stack, see this [tutorial on using `cron` and `mail`](https://k6.io/blog/performance-monitoring-with-cron-and-k6/).
-
 For a more comprehensive solution, you can use [Grafana Cloud Synthetic Monitoring](https://grafana.com/docs/grafana-cloud/testing/synthetic-monitoring/create-checks/checks/k6/) to proactively monitor your application and services in production. You can run k6 smoke tests at frequent intervals, receive alerts on potential issues, and manage incidents directly from [Grafana Cloud](https://grafana.com/products/cloud/).