From 32c8498c60040e7c1a58aba3328cb2d0ed7b4351 Mon Sep 17 00:00:00 2001 From: Thomas Lehner <67914368+ThomasLehnerSpryker@users.noreply.github.com> Date: Fri, 10 Jan 2025 10:49:58 +0100 Subject: [PATCH 1/5] Update environment-scaling.md explained load testing process in more detail --- docs/ca/dev/environment-scaling.md | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/docs/ca/dev/environment-scaling.md b/docs/ca/dev/environment-scaling.md index d1f9c8f9aa..e592ab5f25 100644 --- a/docs/ca/dev/environment-scaling.md +++ b/docs/ca/dev/environment-scaling.md @@ -7,6 +7,12 @@ template: concept-topic-template Production environments, unlike staging environments, are equipped with auto-scaling capabilities. This enables the resources used by the application to dynamically scale up or down based on the current load. This document uses the checkout analogy as an example to explain the types of scaling. +{% info_block infoBox "" %} +* While all production environments offer some form of automatic scaling by default, environments must be optimized for your work load. Please schedule a Load Test using the "Announce High Load/Traffic" topic in our Support Portal. Please allow for at least 3 days of lead time. +* Load tests usually are performed in rounds. After deploying a typical infrastructure configuration for the size of your project, you will be asked to perform your load testing. The results are analysed and the environment dialed in. This pattern is repeated until the environment is configured to support the expected load. Typically 2-3 rounds are necessary. +* We do not recomment load tests to be conducted on live production environments due to the risk of impacting the applications performance for your visitors. We instead recommend booking a production-like environment or upgrading one of your non-production environments to this size to be able to perform tests without risking spillover. +{% endinfo_block %} + ## Cloud architecture EC2 hosts are used to deploy Docker containers. One host generally has multiple containers running with Spryker services, such as Yves and BackGW. The containers may only reserve up to the configured amount of CPU and RAM of the host machine. Additional hosts, up to a configured maximum number of hosts, are deployed as needed so that more containers can be placed on them in scaling events. From 8f30ea360611c0c0f13cbb8c6ec431d7dac5a2a8 Mon Sep 17 00:00:00 2001 From: vol4onok Date: Mon, 13 Jan 2025 14:13:31 +0200 Subject: [PATCH 2/5] SUPESC-930: Updated doc to use json value without whitespaces --- docs/ca/devscu/configure-spryker-code-upgrader.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/docs/ca/devscu/configure-spryker-code-upgrader.md b/docs/ca/devscu/configure-spryker-code-upgrader.md index 7d95c00109..a7c5117f7e 100644 --- a/docs/ca/devscu/configure-spryker-code-upgrader.md +++ b/docs/ca/devscu/configure-spryker-code-upgrader.md @@ -1,6 +1,6 @@ --- title: Configure Spryker Code Upgrader -description: Configure Spryker Code Upgrader with custom variables for pipelines, including cron schedules and version limits, to tailor updates to your project needs. +description: Instructions for configuration of Spryker Code Upgrader template: concept-topic-template last_updated: Aug 15, 2023 redirect_from: @@ -28,6 +28,8 @@ To configure the Upgrader, follow the steps: ![Spryker CI Set Config Upgrader Pipeline](https://spryker.s3.eu-central-1.amazonaws.com/docs/paas%2B/dev/configure-spryker-code-upgrader.md/set-spryker-code-upgrader-variables.png) +Note: The JSON value should be in one line and without whitespaces. + This runs the pipeline. After it finishes, the configuration gets updated. ## Customization variables From 3b6788c9cdf588da4ecd5ab8e23985aabc914a99 Mon Sep 17 00:00:00 2001 From: vol4onok Date: Mon, 13 Jan 2025 14:21:21 +0200 Subject: [PATCH 3/5] SUPESC-930: Updated doc to use json value without whitespaces --- docs/ca/devscu/configure-spryker-code-upgrader.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/ca/devscu/configure-spryker-code-upgrader.md b/docs/ca/devscu/configure-spryker-code-upgrader.md index a7c5117f7e..98533f79ca 100644 --- a/docs/ca/devscu/configure-spryker-code-upgrader.md +++ b/docs/ca/devscu/configure-spryker-code-upgrader.md @@ -1,6 +1,6 @@ --- title: Configure Spryker Code Upgrader -description: Instructions for configuration of Spryker Code Upgrader +description: Configure Spryker Code Upgrader with custom variables for pipelines, including cron schedules and version limits, to tailor updates to your project needs. template: concept-topic-template last_updated: Aug 15, 2023 redirect_from: From 33f18021127b418d7dc1c92d6b0117cd65b58816 Mon Sep 17 00:00:00 2001 From: Andrii Tserkovnyi Date: Tue, 14 Jan 2025 18:12:28 +0800 Subject: [PATCH 4/5] Update configure-spryker-code-upgrader.md --- docs/ca/devscu/configure-spryker-code-upgrader.md | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/docs/ca/devscu/configure-spryker-code-upgrader.md b/docs/ca/devscu/configure-spryker-code-upgrader.md index 98533f79ca..12392a9d0e 100644 --- a/docs/ca/devscu/configure-spryker-code-upgrader.md +++ b/docs/ca/devscu/configure-spryker-code-upgrader.md @@ -26,9 +26,13 @@ To configure the Upgrader, follow the steps: 5. On the **Run: #1** page, update the needed parameters and click **Proceed**. -![Spryker CI Set Config Upgrader Pipeline](https://spryker.s3.eu-central-1.amazonaws.com/docs/paas%2B/dev/configure-spryker-code-upgrader.md/set-spryker-code-upgrader-variables.png) +{% info_block infoBox %} + +JSON values must be added in one line and without whitespaces. -Note: The JSON value should be in one line and without whitespaces. +{% endinfo_block %} + +![Spryker CI Set Config Upgrader Pipeline](https://spryker.s3.eu-central-1.amazonaws.com/docs/paas%2B/dev/configure-spryker-code-upgrader.md/set-spryker-code-upgrader-variables.png) This runs the pipeline. After it finishes, the configuration gets updated. From b560f90119d1e087078301958ba7e39d845af734 Mon Sep 17 00:00:00 2001 From: Andrii Tserkovnyi Date: Tue, 14 Jan 2025 18:47:47 +0800 Subject: [PATCH 5/5] Update environment-scaling.md --- docs/ca/dev/environment-scaling.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/docs/ca/dev/environment-scaling.md b/docs/ca/dev/environment-scaling.md index e592ab5f25..b26e7a84f4 100644 --- a/docs/ca/dev/environment-scaling.md +++ b/docs/ca/dev/environment-scaling.md @@ -8,9 +8,9 @@ template: concept-topic-template Production environments, unlike staging environments, are equipped with auto-scaling capabilities. This enables the resources used by the application to dynamically scale up or down based on the current load. This document uses the checkout analogy as an example to explain the types of scaling. {% info_block infoBox "" %} -* While all production environments offer some form of automatic scaling by default, environments must be optimized for your work load. Please schedule a Load Test using the "Announce High Load/Traffic" topic in our Support Portal. Please allow for at least 3 days of lead time. -* Load tests usually are performed in rounds. After deploying a typical infrastructure configuration for the size of your project, you will be asked to perform your load testing. The results are analysed and the environment dialed in. This pattern is repeated until the environment is configured to support the expected load. Typically 2-3 rounds are necessary. -* We do not recomment load tests to be conducted on live production environments due to the risk of impacting the applications performance for your visitors. We instead recommend booking a production-like environment or upgrading one of your non-production environments to this size to be able to perform tests without risking spillover. +* While all production environments offer some form of automatic scaling by default, environments must be optimized for your work load. To do it, schedule a load test by creating a "Announce High Load/Traffic" case at the [support portal](https://support.spryker.com). Plan for at least three days of lead time. +* Load tests are usually performed in rounds. After deploying a typical infrastructure configuration for the size of your project, we'll ask you to perform load testing. The results are analyzed and the environment is dialed in. This pattern is repeated until the environment is configured to support the expected load. For a good result, two to three rounds are needed. +* We don't recomment load testing in live production environments because this can affect the experience of your visitors. Instead, book a production-like environment or upgrade one of your non-production environments to perform the tests. {% endinfo_block %} ## Cloud architecture