From 473366824f57ff2bf4135ad7e31eba457812df6a Mon Sep 17 00:00:00 2001 From: mdcruz Date: Wed, 29 Nov 2023 13:58:01 +0000 Subject: [PATCH 1/3] docs: add a few more k6 browser examples --- .../browser/browsercontext/newpage.md | 3 +- docs/sources/next/using-k6-browser/metrics.md | 72 +++++++ .../recommended-practices/_index.md | 1 + .../hybrid-approach-to-performance.md | 197 ++++++++++++++++++ .../page-object-model-pattern.md | 2 +- .../selecting-elements.md | 2 +- .../browser/browsercontext/newpage.md | 3 +- .../v0.47.x/using-k6-browser/metrics.md | 72 +++++++ .../recommended-practices/_index.md | 1 + .../hybrid-approach-to-performance.md | 197 ++++++++++++++++++ 10 files changed, 546 insertions(+), 4 deletions(-) create mode 100644 docs/sources/next/using-k6-browser/recommended-practices/hybrid-approach-to-performance.md create mode 100644 docs/sources/v0.47.x/using-k6-browser/recommended-practices/hybrid-approach-to-performance.md diff --git a/docs/sources/next/javascript-api/k6-experimental/browser/browsercontext/newpage.md b/docs/sources/next/javascript-api/k6-experimental/browser/browsercontext/newpage.md index 340fc44d47..dac29e2412 100644 --- a/docs/sources/next/javascript-api/k6-experimental/browser/browsercontext/newpage.md +++ b/docs/sources/next/javascript-api/k6-experimental/browser/browsercontext/newpage.md @@ -21,7 +21,8 @@ Uses the `BrowserContext` to create a new [Page](https://grafana.com/docs/k6/}} + +```javascript +import { browser } from "k6/experimental/browser"; +import { Trend } from "k6/metrics"; + +export const options = { + scenarios: { + ui: { + executor: "shared-iterations", + options: { + browser: { + type: "chromium", + }, + }, + }, + }, +}; + +const myTrend = new Trend('total_action_time'); + +export default async function () { + const page = browser.newPage(); + + try { + await page.goto('https://test.k6.io/browser.php'); + page.evaluate(() => window.performance.mark('page-visit')); + + page.locator('#checkbox1').check(); + page.locator('#counter-button"]').click(); + page.locator('#text1').fill('This is a test'); + + page.evaluate(() => window.performance.mark('action-completed')); + + // Get time difference between visiting the page and completing the actions + page.evaluate(() => + window.performance.measure( + 'total-action-time', + 'page-visit', + 'action-completed', + ) + ); + + const totalActionTime = page.evaluate(() => + JSON.parse(JSON.stringify(window.performance.getEntriesByName('total-action-time')))[0].duration + ); + + myTrend.add(total_action_time); + } finally { + page.close(); + } +} +``` + +{{< /code >}} + +When the test is run, you should see a similar output as the one below. + +```bash + iteration_duration..........: avg=1.06s min=1.06s med=1.06s max=1.06s p(90)=1.06s p(95)=1.06s + iterations..................: 1 0.70866/s + total_action_time.............: avg=295.3 min=295.3 med=295.3 max=295.3 p(90)=295.3 p(95)=295.3 +``` \ No newline at end of file diff --git a/docs/sources/next/using-k6-browser/recommended-practices/_index.md b/docs/sources/next/using-k6-browser/recommended-practices/_index.md index 59c8cf3382..c45219d7a6 100644 --- a/docs/sources/next/using-k6-browser/recommended-practices/_index.md +++ b/docs/sources/next/using-k6-browser/recommended-practices/_index.md @@ -9,5 +9,6 @@ weight: 100 This section presents some examples and recommended practices when working with the `k6 browser` module to leverage browser automation as part of your k6 tests. +- [Hybrid approach to performance](https://grafana.com/docs/k6//using-k6-browser/recommended-practices/hybrid-approach-to-performance) - [Page object model pattern](https://grafana.com/docs/k6//using-k6-browser/recommended-practices/page-object-model-pattern) - [Selecting elements](https://grafana.com/docs/k6//using-k6-browser/recommended-practices/selecting-elements) diff --git a/docs/sources/next/using-k6-browser/recommended-practices/hybrid-approach-to-performance.md b/docs/sources/next/using-k6-browser/recommended-practices/hybrid-approach-to-performance.md new file mode 100644 index 0000000000..32f5e13e06 --- /dev/null +++ b/docs/sources/next/using-k6-browser/recommended-practices/hybrid-approach-to-performance.md @@ -0,0 +1,197 @@ +--- +title: 'Hybrid approach to performance' +heading: 'Hybrid performance with k6 browser' +head_title: 'Hybrid performance with k6 browser' +excerpt: 'An example on how to implement a hybrid approach to performance with k6 browser' +weight: 01 +--- + +# Hybrid performance with k6 browser + +An alternative approach to [browser-based load testing](https://grafana.com/docs/k6//testing-guides/load-testing-websites/#browser-based-load-testing) that is much less resource-intensive is combining a low amount of virtual users for a browser test with a high amount of virtual users for a protocol-level test. + +Hybrid performance can be achieved in multiple ways, often using different tools. To simplify the developer experience, k6 browser can be easily combined with core k6 features, so you can easily write hybrid tests in a single script. + +## Browser and HTTP test + +The code below shows an example of combining a browser and HTTP test in a single script. While the backend is exposed to the typical load, the frontend is also checked for any unexpected issues. Thresholds are defined to check both HTTP and browser metrics against pre-defined SLOs. + +{{< code >}} + +```javascript +import http from "k6/http"; +import { check } from "k6"; +import { browser } from "k6/experimental/browser"; + +const BASE_URL = __ENV.BASE_URL; + +export const options = { + scenarios: { + load: { + exec: 'getPizza', + executor: 'ramping-vus', + stages: [ + { duration: '5s', target: 5 }, + { duration: '10s', target: 5 }, + { duration: '5s', target: 0 }, + ], + startTime: '10s', + }, + browser: { + exec: 'checkFrontend', + executor: 'constant-vus', + vus: 1, + duration: '30s', + options: { + browser: { + type: 'chromium', + }, + }, + } + }, + thresholds: { + http_req_failed: ['rate<0.01'], + http_req_duration: ['p(95)<500', 'p(99)<1000'], + browser_web_vital_fcp: ["p(95) < 1000"], + browser_web_vital_lcp: ["p(95) < 2000"], + }, +}; + +export function getPizza() { + let restrictions = { + maxCaloriesPerSlice: 500, + mustBeVegetarian: false, + excludedIngredients: ['pepperoni'], + excludedTools: ['knife'], + maxNumberOfToppings: 6, + minNumberOfToppings: 2 + } + + let res = http.post(`${BASE_URL}/api/pizza`, JSON.stringify(restrictions), { + headers: { + 'Content-Type': 'application/json', + 'X-User-ID': customers[Math.floor(Math.random() * customers.length)], + }, + }); + + check(res, { + 'status is 200': (res) => res.status === 200 + }); +} + +export async function checkFrontend() { + const page = browser.newPage(); + + try { + await page.goto(BASE_URL) + check(page, { + 'header': page.locator('h1').textContent() == 'Looking to break out of your pizza routine?', + }); + + await page.locator('//button[. = "Pizza, Please!"]').click(); + page.waitForTimeout(500); + page.screenshot({ path: `screenshots/${__ITER}.png` }); + + check(page, { + 'recommendation': page.locator('div#recommendations').textContent() != '', + }); + } finally { + page.close(); + } +} + +``` + +{{< /code >}} + +## Browser and failure injection test + +A browser test can also be run with a failure injection test via the [xk6-disruptor](https://github.com/grafana/xk6-disruptor) extension. This approach lets you find issues in your front end if any services it depends on are suddenly injected with failures, such as delays or server errors. + +The code below shows an example of introducing faults to a Kubernetes service. While this happens, the `browser` scenario is also executed, which checks the frontend application for unexpected errors that might not have been handled properly. + +To find out more information about injecting faults to your service, check out our [get started guide with xk6-disruptor](https://grafana.com/docs/k6//javascript-api/xk6-disruptor/get-started/). + +{{< code >}} + +```javascript +import http from "k6/http"; +import { check } from "k6"; +import { browser } from "k6/experimental/browser"; + +const BASE_URL = __ENV.BASE_URL; + +export const options = { + scenarios: { + disrupt: { + executor: "shared-iterations", + iterations: 1, + vus: 1, + exec: "disrupt", + }, + browser: { + executor: "constant-vus", + vus: 1, + duration: "10s", + startTime: "10s", + exec: "browser", + options: { + browser: { + type: "chromium", + }, + }, + }, + }, + thresholds: { + browser_web_vital_fcp: ["p(95) < 1000"], + browser_web_vital_lcp: ["p(95) < 2000"], + }, +}; + +// Add faults to the service by introducing a delay of 1s and 503 errors to 10% of the requests. +const fault = { + averageDelay: "1000ms", + errorRate: 0.1, + errorCode: 503, +} + +export function disrupt() { + const disruptor = new ServiceDisruptor("pizza-info", "pizza-ns"); + const targets = disruptor.targets(); + if (targets.length == 0) { + throw new Error("expected list to have one target"); + } + + disruptor.injectHTTPFaults(fault, "20s"); +} + +export async function checkFrontend() { + const page = browser.newPage(); + + try { + await page.goto(BASE_URL) + check(page, { + 'header': page.locator('h1').textContent() == 'Looking to break out of your pizza routine?', + }); + + await page.locator('//button[. = "Pizza, Please!"]').click(); + page.waitForTimeout(500); + page.screenshot({ path: `screenshots/${__ITER}.png` }); + + check(page, { + 'recommendation': page.locator('div#recommendations').textContent() != '', + }); + } finally { + page.close(); + } +} + +``` + +{{< /code >}} + +## Recommended practices + +- **Do start small**. Start with a low amount of browser-based virtual users. A good starting point is to have 10% virtual users or less to monitor the user experience for your end-users, while around 90% of traffic should be emulated from the protocol level. +- **Combine browser test with different load testing types**. To fully understand the impact of different traffic patterns on your end-user experience, experiment with running your browser test with different [load testing types](https://grafana.com/docs/k6//testing-guides/test-types/). +- **Cover high-risk user journeys as a start**. Consider identifying the high-risk user journeys first so you can start to monitor the web performance metrics for these user journeys while your backend applications are being exposed to high traffic or service faults. \ No newline at end of file diff --git a/docs/sources/next/using-k6-browser/recommended-practices/page-object-model-pattern.md b/docs/sources/next/using-k6-browser/recommended-practices/page-object-model-pattern.md index b7e714117f..dec965a291 100644 --- a/docs/sources/next/using-k6-browser/recommended-practices/page-object-model-pattern.md +++ b/docs/sources/next/using-k6-browser/recommended-practices/page-object-model-pattern.md @@ -3,7 +3,7 @@ title: 'Page object model' heading: 'Page object model with k6 browser' head_title: 'Page object model with k6 browser' excerpt: 'An example on how to implement page object model design pattern with k6 browser' -weight: 01 +weight: 02 --- # Page object model diff --git a/docs/sources/next/using-k6-browser/recommended-practices/selecting-elements.md b/docs/sources/next/using-k6-browser/recommended-practices/selecting-elements.md index 3075a643eb..dadd2545bf 100644 --- a/docs/sources/next/using-k6-browser/recommended-practices/selecting-elements.md +++ b/docs/sources/next/using-k6-browser/recommended-practices/selecting-elements.md @@ -1,7 +1,7 @@ --- title: 'Selecting elements' excerpt: 'A guide on how to select elements with the browser module.' -weight: 02 +weight: 03 --- # Selecting elements diff --git a/docs/sources/v0.47.x/javascript-api/k6-experimental/browser/browsercontext/newpage.md b/docs/sources/v0.47.x/javascript-api/k6-experimental/browser/browsercontext/newpage.md index 340fc44d47..dac29e2412 100644 --- a/docs/sources/v0.47.x/javascript-api/k6-experimental/browser/browsercontext/newpage.md +++ b/docs/sources/v0.47.x/javascript-api/k6-experimental/browser/browsercontext/newpage.md @@ -21,7 +21,8 @@ Uses the `BrowserContext` to create a new [Page](https://grafana.com/docs/k6/}} + +```javascript +import { browser } from "k6/experimental/browser"; +import { Trend } from "k6/metrics"; + +export const options = { + scenarios: { + ui: { + executor: "shared-iterations", + options: { + browser: { + type: "chromium", + }, + }, + }, + }, +}; + +const myTrend = new Trend('total_action_time'); + +export default async function () { + const page = browser.newPage(); + + try { + await page.goto('https://test.k6.io/browser.php'); + page.evaluate(() => window.performance.mark('page-visit')); + + page.locator('#checkbox1').check(); + page.locator('#counter-button"]').click(); + page.locator('#text1').fill('This is a test'); + + page.evaluate(() => window.performance.mark('action-completed')); + + // Get time difference between visiting the page and completing the actions + page.evaluate(() => + window.performance.measure( + 'total-action-time', + 'page-visit', + 'action-completed', + ) + ); + + const totalActionTime = page.evaluate(() => + JSON.parse(JSON.stringify(window.performance.getEntriesByName('total-action-time')))[0].duration + ); + + myTrend.add(total_action_time); + } finally { + page.close(); + } +} +``` + +{{< /code >}} + +When the test is run, you should see a similar output as the one below. + +```bash + iteration_duration..........: avg=1.06s min=1.06s med=1.06s max=1.06s p(90)=1.06s p(95)=1.06s + iterations..................: 1 0.70866/s + total_action_time.............: avg=295.3 min=295.3 med=295.3 max=295.3 p(90)=295.3 p(95)=295.3 +``` diff --git a/docs/sources/v0.47.x/using-k6-browser/recommended-practices/_index.md b/docs/sources/v0.47.x/using-k6-browser/recommended-practices/_index.md index 59c8cf3382..c45219d7a6 100644 --- a/docs/sources/v0.47.x/using-k6-browser/recommended-practices/_index.md +++ b/docs/sources/v0.47.x/using-k6-browser/recommended-practices/_index.md @@ -9,5 +9,6 @@ weight: 100 This section presents some examples and recommended practices when working with the `k6 browser` module to leverage browser automation as part of your k6 tests. +- [Hybrid approach to performance](https://grafana.com/docs/k6//using-k6-browser/recommended-practices/hybrid-approach-to-performance) - [Page object model pattern](https://grafana.com/docs/k6//using-k6-browser/recommended-practices/page-object-model-pattern) - [Selecting elements](https://grafana.com/docs/k6//using-k6-browser/recommended-practices/selecting-elements) diff --git a/docs/sources/v0.47.x/using-k6-browser/recommended-practices/hybrid-approach-to-performance.md b/docs/sources/v0.47.x/using-k6-browser/recommended-practices/hybrid-approach-to-performance.md new file mode 100644 index 0000000000..32f5e13e06 --- /dev/null +++ b/docs/sources/v0.47.x/using-k6-browser/recommended-practices/hybrid-approach-to-performance.md @@ -0,0 +1,197 @@ +--- +title: 'Hybrid approach to performance' +heading: 'Hybrid performance with k6 browser' +head_title: 'Hybrid performance with k6 browser' +excerpt: 'An example on how to implement a hybrid approach to performance with k6 browser' +weight: 01 +--- + +# Hybrid performance with k6 browser + +An alternative approach to [browser-based load testing](https://grafana.com/docs/k6//testing-guides/load-testing-websites/#browser-based-load-testing) that is much less resource-intensive is combining a low amount of virtual users for a browser test with a high amount of virtual users for a protocol-level test. + +Hybrid performance can be achieved in multiple ways, often using different tools. To simplify the developer experience, k6 browser can be easily combined with core k6 features, so you can easily write hybrid tests in a single script. + +## Browser and HTTP test + +The code below shows an example of combining a browser and HTTP test in a single script. While the backend is exposed to the typical load, the frontend is also checked for any unexpected issues. Thresholds are defined to check both HTTP and browser metrics against pre-defined SLOs. + +{{< code >}} + +```javascript +import http from "k6/http"; +import { check } from "k6"; +import { browser } from "k6/experimental/browser"; + +const BASE_URL = __ENV.BASE_URL; + +export const options = { + scenarios: { + load: { + exec: 'getPizza', + executor: 'ramping-vus', + stages: [ + { duration: '5s', target: 5 }, + { duration: '10s', target: 5 }, + { duration: '5s', target: 0 }, + ], + startTime: '10s', + }, + browser: { + exec: 'checkFrontend', + executor: 'constant-vus', + vus: 1, + duration: '30s', + options: { + browser: { + type: 'chromium', + }, + }, + } + }, + thresholds: { + http_req_failed: ['rate<0.01'], + http_req_duration: ['p(95)<500', 'p(99)<1000'], + browser_web_vital_fcp: ["p(95) < 1000"], + browser_web_vital_lcp: ["p(95) < 2000"], + }, +}; + +export function getPizza() { + let restrictions = { + maxCaloriesPerSlice: 500, + mustBeVegetarian: false, + excludedIngredients: ['pepperoni'], + excludedTools: ['knife'], + maxNumberOfToppings: 6, + minNumberOfToppings: 2 + } + + let res = http.post(`${BASE_URL}/api/pizza`, JSON.stringify(restrictions), { + headers: { + 'Content-Type': 'application/json', + 'X-User-ID': customers[Math.floor(Math.random() * customers.length)], + }, + }); + + check(res, { + 'status is 200': (res) => res.status === 200 + }); +} + +export async function checkFrontend() { + const page = browser.newPage(); + + try { + await page.goto(BASE_URL) + check(page, { + 'header': page.locator('h1').textContent() == 'Looking to break out of your pizza routine?', + }); + + await page.locator('//button[. = "Pizza, Please!"]').click(); + page.waitForTimeout(500); + page.screenshot({ path: `screenshots/${__ITER}.png` }); + + check(page, { + 'recommendation': page.locator('div#recommendations').textContent() != '', + }); + } finally { + page.close(); + } +} + +``` + +{{< /code >}} + +## Browser and failure injection test + +A browser test can also be run with a failure injection test via the [xk6-disruptor](https://github.com/grafana/xk6-disruptor) extension. This approach lets you find issues in your front end if any services it depends on are suddenly injected with failures, such as delays or server errors. + +The code below shows an example of introducing faults to a Kubernetes service. While this happens, the `browser` scenario is also executed, which checks the frontend application for unexpected errors that might not have been handled properly. + +To find out more information about injecting faults to your service, check out our [get started guide with xk6-disruptor](https://grafana.com/docs/k6//javascript-api/xk6-disruptor/get-started/). + +{{< code >}} + +```javascript +import http from "k6/http"; +import { check } from "k6"; +import { browser } from "k6/experimental/browser"; + +const BASE_URL = __ENV.BASE_URL; + +export const options = { + scenarios: { + disrupt: { + executor: "shared-iterations", + iterations: 1, + vus: 1, + exec: "disrupt", + }, + browser: { + executor: "constant-vus", + vus: 1, + duration: "10s", + startTime: "10s", + exec: "browser", + options: { + browser: { + type: "chromium", + }, + }, + }, + }, + thresholds: { + browser_web_vital_fcp: ["p(95) < 1000"], + browser_web_vital_lcp: ["p(95) < 2000"], + }, +}; + +// Add faults to the service by introducing a delay of 1s and 503 errors to 10% of the requests. +const fault = { + averageDelay: "1000ms", + errorRate: 0.1, + errorCode: 503, +} + +export function disrupt() { + const disruptor = new ServiceDisruptor("pizza-info", "pizza-ns"); + const targets = disruptor.targets(); + if (targets.length == 0) { + throw new Error("expected list to have one target"); + } + + disruptor.injectHTTPFaults(fault, "20s"); +} + +export async function checkFrontend() { + const page = browser.newPage(); + + try { + await page.goto(BASE_URL) + check(page, { + 'header': page.locator('h1').textContent() == 'Looking to break out of your pizza routine?', + }); + + await page.locator('//button[. = "Pizza, Please!"]').click(); + page.waitForTimeout(500); + page.screenshot({ path: `screenshots/${__ITER}.png` }); + + check(page, { + 'recommendation': page.locator('div#recommendations').textContent() != '', + }); + } finally { + page.close(); + } +} + +``` + +{{< /code >}} + +## Recommended practices + +- **Do start small**. Start with a low amount of browser-based virtual users. A good starting point is to have 10% virtual users or less to monitor the user experience for your end-users, while around 90% of traffic should be emulated from the protocol level. +- **Combine browser test with different load testing types**. To fully understand the impact of different traffic patterns on your end-user experience, experiment with running your browser test with different [load testing types](https://grafana.com/docs/k6//testing-guides/test-types/). +- **Cover high-risk user journeys as a start**. Consider identifying the high-risk user journeys first so you can start to monitor the web performance metrics for these user journeys while your backend applications are being exposed to high traffic or service faults. \ No newline at end of file From c568b9fdd6313b2989e055a2774254360f786e07 Mon Sep 17 00:00:00 2001 From: Marie Cruz Date: Thu, 30 Nov 2023 09:31:07 +0000 Subject: [PATCH 2/3] Apply suggestions from code review Co-authored-by: Heitor Tashiro Sergent --- docs/sources/next/using-k6-browser/metrics.md | 10 ++++------ .../hybrid-approach-to-performance.md | 16 ++++++++-------- 2 files changed, 12 insertions(+), 14 deletions(-) diff --git a/docs/sources/next/using-k6-browser/metrics.md b/docs/sources/next/using-k6-browser/metrics.md index de5643341a..19f3980819 100644 --- a/docs/sources/next/using-k6-browser/metrics.md +++ b/docs/sources/next/using-k6-browser/metrics.md @@ -101,11 +101,9 @@ When the test is run, you should see a similar output as the one below. ## Measure custom metrics -Through k6 browser's `page.evaluate` function, you can call the [Performance API](https://developer.mozilla.org/en-US/docs/Web/API/Performance_API) to measure the performance of web applications. As an example, if you want to measure the time it takes for your users to complete actions, such as a search feature, then you can use the [`performance.mark`](https://developer.mozilla.org/en-US/docs/Web/API/Performance/mark) method to add a timestamp in your browser's performance timeline. - -To measure the time difference between two performance markers, you can use the [`performance.measure`](https://developer.mozilla.org/en-US/docs/Web/API/Performance/measure) method. - -The time duration that is returned by the performance measure can be added as custom metric in k6 browser using [Trends](https://k6.io/docs/javascript-api/k6-metrics/trend/). +When using the k6 browser `page.evaluate` function, you can call the [Performance API](https://developer.mozilla.org/en-US/docs/Web/API/Performance_API) to measure the performance of web applications. For example, if you want to measure the time it takes for your users to complete actions, such as a search feature, you can use the [`performance.mark`](https://developer.mozilla.org/en-US/docs/Web/API/Performance/mark) method to add a timestamp in your browser's performance timeline. + +Using the [`performance.measure`](https://developer.mozilla.org/en-US/docs/Web/API/Performance/measure) method, you can also measure the time difference between two performance markers. The time duration that `performance.measure` returns can be added as a custom metric in k6 browser using [Trends](https://k6.io/docs/javascript-api/k6-metrics/trend/). {{< code >}} @@ -163,7 +161,7 @@ export default async function () { {{< /code >}} -When the test is run, you should see a similar output as the one below. +After you run the test, you should see a similar output as the one below. ```bash iteration_duration..........: avg=1.06s min=1.06s med=1.06s max=1.06s p(90)=1.06s p(95)=1.06s diff --git a/docs/sources/next/using-k6-browser/recommended-practices/hybrid-approach-to-performance.md b/docs/sources/next/using-k6-browser/recommended-practices/hybrid-approach-to-performance.md index 32f5e13e06..54efeedad9 100644 --- a/docs/sources/next/using-k6-browser/recommended-practices/hybrid-approach-to-performance.md +++ b/docs/sources/next/using-k6-browser/recommended-practices/hybrid-approach-to-performance.md @@ -8,13 +8,13 @@ weight: 01 # Hybrid performance with k6 browser -An alternative approach to [browser-based load testing](https://grafana.com/docs/k6//testing-guides/load-testing-websites/#browser-based-load-testing) that is much less resource-intensive is combining a low amount of virtual users for a browser test with a high amount of virtual users for a protocol-level test. +An alternative approach to [browser-based load testing](https://grafana.com/docs/k6//testing-guides/load-testing-websites/#browser-based-load-testing) that's much less resource-intensive is combining a small number of virtual users for a browser test with a large number of virtual users for a protocol-level test. -Hybrid performance can be achieved in multiple ways, often using different tools. To simplify the developer experience, k6 browser can be easily combined with core k6 features, so you can easily write hybrid tests in a single script. +You can achieve hybrid performance in multiple ways, often by using different tools. To simplify the developer experience, you can combine k6 browser with core k6 features to write hybrid tests in a single script. ## Browser and HTTP test -The code below shows an example of combining a browser and HTTP test in a single script. While the backend is exposed to the typical load, the frontend is also checked for any unexpected issues. Thresholds are defined to check both HTTP and browser metrics against pre-defined SLOs. +The code below shows an example of combining a browser and HTTP test in a single script. While the script exposes the backend to the typical load, it also checks the frontend for any unexpected issues. It also defines thresholds to check both HTTP and browser metrics against pre-defined SLOs. {{< code >}} @@ -106,11 +106,11 @@ export async function checkFrontend() { ## Browser and failure injection test -A browser test can also be run with a failure injection test via the [xk6-disruptor](https://github.com/grafana/xk6-disruptor) extension. This approach lets you find issues in your front end if any services it depends on are suddenly injected with failures, such as delays or server errors. +You can also run a browser test together with a failure injection test by using the [xk6-disruptor](https://github.com/grafana/xk6-disruptor) extension. This approach lets you find issues in your front end if any services it depends on are suddenly injected with failures, such as delays or server errors. -The code below shows an example of introducing faults to a Kubernetes service. While this happens, the `browser` scenario is also executed, which checks the frontend application for unexpected errors that might not have been handled properly. +The following code shows an example of how to introduce faults to a Kubernetes service. At the same time, the `browser` scenario runs to ensure the frontend application is free of any unexpected errors that may not have been handled properly. -To find out more information about injecting faults to your service, check out our [get started guide with xk6-disruptor](https://grafana.com/docs/k6//javascript-api/xk6-disruptor/get-started/). +To find out more information about injecting faults to your service, check out the [Get started with xk6-disruptor guide](https://grafana.com/docs/k6//javascript-api/xk6-disruptor/get-started/). {{< code >}} @@ -192,6 +192,6 @@ export async function checkFrontend() { ## Recommended practices -- **Do start small**. Start with a low amount of browser-based virtual users. A good starting point is to have 10% virtual users or less to monitor the user experience for your end-users, while around 90% of traffic should be emulated from the protocol level. +- **Start small**. Start with a small number of browser-based virtual users. A good starting point is to have 10% virtual users or less to monitor the user experience for your end-users, while the script emulates around 90% of traffic from the protocol level. - **Combine browser test with different load testing types**. To fully understand the impact of different traffic patterns on your end-user experience, experiment with running your browser test with different [load testing types](https://grafana.com/docs/k6//testing-guides/test-types/). -- **Cover high-risk user journeys as a start**. Consider identifying the high-risk user journeys first so you can start to monitor the web performance metrics for these user journeys while your backend applications are being exposed to high traffic or service faults. \ No newline at end of file +- **Focus on high-risk user journeys as a start**. Identify the high-risk user journeys first so you can start monitoring the web performance metrics for them while your backend applications are being exposed to high traffic or service faults. \ No newline at end of file From d9963982807cf6b7d622ddf57ab7b1b65161c421 Mon Sep 17 00:00:00 2001 From: mdcruz Date: Thu, 30 Nov 2023 09:43:47 +0000 Subject: [PATCH 3/3] docs: apply patch from latest --- docs/sources/v0.47.x/using-k6-browser/metrics.md | 12 +++++------- .../hybrid-approach-to-performance.md | 16 ++++++++-------- 2 files changed, 13 insertions(+), 15 deletions(-) diff --git a/docs/sources/v0.47.x/using-k6-browser/metrics.md b/docs/sources/v0.47.x/using-k6-browser/metrics.md index 7bd679de39..19f3980819 100644 --- a/docs/sources/v0.47.x/using-k6-browser/metrics.md +++ b/docs/sources/v0.47.x/using-k6-browser/metrics.md @@ -101,11 +101,9 @@ When the test is run, you should see a similar output as the one below. ## Measure custom metrics -Through k6 browser's `page.evaluate` function, you can call the [Performance API](https://developer.mozilla.org/en-US/docs/Web/API/Performance_API) to measure the performance of web applications. As an example, if you want to measure the time it takes for your users to complete actions, such as a search feature, then you can use the [`performance.mark`](https://developer.mozilla.org/en-US/docs/Web/API/Performance/mark) method to add a timestamp in your browser's performance timeline. - -To measure the time difference between two performance markers, you can use the [`performance.measure`](https://developer.mozilla.org/en-US/docs/Web/API/Performance/measure) method. - -The time duration that is returned by the performance measure can be added as custom metric in k6 browser using [Trends](https://k6.io/docs/javascript-api/k6-metrics/trend/). +When using the k6 browser `page.evaluate` function, you can call the [Performance API](https://developer.mozilla.org/en-US/docs/Web/API/Performance_API) to measure the performance of web applications. For example, if you want to measure the time it takes for your users to complete actions, such as a search feature, you can use the [`performance.mark`](https://developer.mozilla.org/en-US/docs/Web/API/Performance/mark) method to add a timestamp in your browser's performance timeline. + +Using the [`performance.measure`](https://developer.mozilla.org/en-US/docs/Web/API/Performance/measure) method, you can also measure the time difference between two performance markers. The time duration that `performance.measure` returns can be added as a custom metric in k6 browser using [Trends](https://k6.io/docs/javascript-api/k6-metrics/trend/). {{< code >}} @@ -163,10 +161,10 @@ export default async function () { {{< /code >}} -When the test is run, you should see a similar output as the one below. +After you run the test, you should see a similar output as the one below. ```bash iteration_duration..........: avg=1.06s min=1.06s med=1.06s max=1.06s p(90)=1.06s p(95)=1.06s iterations..................: 1 0.70866/s total_action_time.............: avg=295.3 min=295.3 med=295.3 max=295.3 p(90)=295.3 p(95)=295.3 -``` +``` \ No newline at end of file diff --git a/docs/sources/v0.47.x/using-k6-browser/recommended-practices/hybrid-approach-to-performance.md b/docs/sources/v0.47.x/using-k6-browser/recommended-practices/hybrid-approach-to-performance.md index 32f5e13e06..54efeedad9 100644 --- a/docs/sources/v0.47.x/using-k6-browser/recommended-practices/hybrid-approach-to-performance.md +++ b/docs/sources/v0.47.x/using-k6-browser/recommended-practices/hybrid-approach-to-performance.md @@ -8,13 +8,13 @@ weight: 01 # Hybrid performance with k6 browser -An alternative approach to [browser-based load testing](https://grafana.com/docs/k6//testing-guides/load-testing-websites/#browser-based-load-testing) that is much less resource-intensive is combining a low amount of virtual users for a browser test with a high amount of virtual users for a protocol-level test. +An alternative approach to [browser-based load testing](https://grafana.com/docs/k6//testing-guides/load-testing-websites/#browser-based-load-testing) that's much less resource-intensive is combining a small number of virtual users for a browser test with a large number of virtual users for a protocol-level test. -Hybrid performance can be achieved in multiple ways, often using different tools. To simplify the developer experience, k6 browser can be easily combined with core k6 features, so you can easily write hybrid tests in a single script. +You can achieve hybrid performance in multiple ways, often by using different tools. To simplify the developer experience, you can combine k6 browser with core k6 features to write hybrid tests in a single script. ## Browser and HTTP test -The code below shows an example of combining a browser and HTTP test in a single script. While the backend is exposed to the typical load, the frontend is also checked for any unexpected issues. Thresholds are defined to check both HTTP and browser metrics against pre-defined SLOs. +The code below shows an example of combining a browser and HTTP test in a single script. While the script exposes the backend to the typical load, it also checks the frontend for any unexpected issues. It also defines thresholds to check both HTTP and browser metrics against pre-defined SLOs. {{< code >}} @@ -106,11 +106,11 @@ export async function checkFrontend() { ## Browser and failure injection test -A browser test can also be run with a failure injection test via the [xk6-disruptor](https://github.com/grafana/xk6-disruptor) extension. This approach lets you find issues in your front end if any services it depends on are suddenly injected with failures, such as delays or server errors. +You can also run a browser test together with a failure injection test by using the [xk6-disruptor](https://github.com/grafana/xk6-disruptor) extension. This approach lets you find issues in your front end if any services it depends on are suddenly injected with failures, such as delays or server errors. -The code below shows an example of introducing faults to a Kubernetes service. While this happens, the `browser` scenario is also executed, which checks the frontend application for unexpected errors that might not have been handled properly. +The following code shows an example of how to introduce faults to a Kubernetes service. At the same time, the `browser` scenario runs to ensure the frontend application is free of any unexpected errors that may not have been handled properly. -To find out more information about injecting faults to your service, check out our [get started guide with xk6-disruptor](https://grafana.com/docs/k6//javascript-api/xk6-disruptor/get-started/). +To find out more information about injecting faults to your service, check out the [Get started with xk6-disruptor guide](https://grafana.com/docs/k6//javascript-api/xk6-disruptor/get-started/). {{< code >}} @@ -192,6 +192,6 @@ export async function checkFrontend() { ## Recommended practices -- **Do start small**. Start with a low amount of browser-based virtual users. A good starting point is to have 10% virtual users or less to monitor the user experience for your end-users, while around 90% of traffic should be emulated from the protocol level. +- **Start small**. Start with a small number of browser-based virtual users. A good starting point is to have 10% virtual users or less to monitor the user experience for your end-users, while the script emulates around 90% of traffic from the protocol level. - **Combine browser test with different load testing types**. To fully understand the impact of different traffic patterns on your end-user experience, experiment with running your browser test with different [load testing types](https://grafana.com/docs/k6//testing-guides/test-types/). -- **Cover high-risk user journeys as a start**. Consider identifying the high-risk user journeys first so you can start to monitor the web performance metrics for these user journeys while your backend applications are being exposed to high traffic or service faults. \ No newline at end of file +- **Focus on high-risk user journeys as a start**. Identify the high-risk user journeys first so you can start monitoring the web performance metrics for them while your backend applications are being exposed to high traffic or service faults. \ No newline at end of file