From 20faadee05d482fe1e8f2fb11fe32666ae978891 Mon Sep 17 00:00:00 2001 From: mrjones <8253488+mrjones-plip@users.noreply.github.com> Date: Mon, 5 Aug 2024 06:45:08 -0700 Subject: [PATCH 1/2] fix 404 on vmware's site --- content/en/hosting/vertical-vs-horizontal.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/en/hosting/vertical-vs-horizontal.md b/content/en/hosting/vertical-vs-horizontal.md index 68e24b0db..0fe53c2a7 100644 --- a/content/en/hosting/vertical-vs-horizontal.md +++ b/content/en/hosting/vertical-vs-horizontal.md @@ -22,7 +22,7 @@ CHT Core 4.0.0 introduces [a new architecture]({{< relref "core/overview/archite Before getting into how the CHT horizontally scales, it should be well understood the importance of vertical scaling and what it is. This is the ability of the CHT to support more users by adding more RAM and CPU to either the bare-metal or virtual machine host. This ensures key services like API, Sentinel and, most importantly, CouchDB, can operate without performance degradation. -When thousands of users are simultaneously trying to synchronize with the CHT, the load can overwhelm CouchDB. As discovered [through extensive research](https://forum.communityhealthtoolkit.org/t/how-we-tested-scalability-of-cht-infrastructure/1532) and [large production deployments](https://github.com/medic/cht-core/issues/8324#issuecomment-1691411542), administrators will start to see errors in their logs and end users will complain of slow sync times. Before moving to more CouchDB nodes, administrators should consider adding more RAM and CPU to the single server where the CHT is hosted. This applies to both CHT 3.x and CHT 4.x. Given the ease of allocating more resources, presumably in virtualized environment like [EC2](https://aws.amazon.com/ec2/), [Proxmox](https://www.vmware.com/content/vmware/vmware-published-sites/us/products/esxi-and-esx.html.html) or [ESXi](https://www.vmware.com/content/vmware/vmware-published-sites/us/products/esxi-and-esx.html.html), this is much easier than moving [from a single to multi-node CouchDB instance]({{< relref "hosting/4.x/data-migration" >}}). +When thousands of users are simultaneously trying to synchronize with the CHT, the load can overwhelm CouchDB. As discovered [through extensive research](https://forum.communityhealthtoolkit.org/t/how-we-tested-scalability-of-cht-infrastructure/1532) and [large production deployments](https://github.com/medic/cht-core/issues/8324#issuecomment-1691411542), administrators will start to see errors in their logs and end users will complain of slow sync times. Before moving to more CouchDB nodes, administrators should consider adding more RAM and CPU to the single server where the CHT is hosted. This applies to both CHT 3.x and CHT 4.x. Given the ease of allocating more resources, presumably in virtualized environment like [EC2](https://aws.amazon.com/ec2/), [Proxmox](https://www.vmware.com/content/vmware/vmware-published-sites/us/products/esxi-and-esx.html.html) or [ESXi](https://www.vmware.com/products/cloud-infrastructure/esxi-and-esx), this is much easier than moving [from a single to multi-node CouchDB instance]({{< relref "hosting/4.x/data-migration" >}}). Here we see a normal deployment following the bare minimum [hosting requirements]({{< relref "hosting/requirements" >}}) for the CHT. We'll call this a "short" deployment because it is not yet vertically scaled: From ac1c70b2d5e760e4a3ae16fac5ae3a5ed8cafee3 Mon Sep 17 00:00:00 2001 From: mrjones Date: Fri, 9 Aug 2024 14:04:35 -0700 Subject: [PATCH 2/2] fix proxmox link per feedback --- content/en/hosting/vertical-vs-horizontal.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/en/hosting/vertical-vs-horizontal.md b/content/en/hosting/vertical-vs-horizontal.md index 0fe53c2a7..058c344f3 100644 --- a/content/en/hosting/vertical-vs-horizontal.md +++ b/content/en/hosting/vertical-vs-horizontal.md @@ -22,7 +22,7 @@ CHT Core 4.0.0 introduces [a new architecture]({{< relref "core/overview/archite Before getting into how the CHT horizontally scales, it should be well understood the importance of vertical scaling and what it is. This is the ability of the CHT to support more users by adding more RAM and CPU to either the bare-metal or virtual machine host. This ensures key services like API, Sentinel and, most importantly, CouchDB, can operate without performance degradation. -When thousands of users are simultaneously trying to synchronize with the CHT, the load can overwhelm CouchDB. As discovered [through extensive research](https://forum.communityhealthtoolkit.org/t/how-we-tested-scalability-of-cht-infrastructure/1532) and [large production deployments](https://github.com/medic/cht-core/issues/8324#issuecomment-1691411542), administrators will start to see errors in their logs and end users will complain of slow sync times. Before moving to more CouchDB nodes, administrators should consider adding more RAM and CPU to the single server where the CHT is hosted. This applies to both CHT 3.x and CHT 4.x. Given the ease of allocating more resources, presumably in virtualized environment like [EC2](https://aws.amazon.com/ec2/), [Proxmox](https://www.vmware.com/content/vmware/vmware-published-sites/us/products/esxi-and-esx.html.html) or [ESXi](https://www.vmware.com/products/cloud-infrastructure/esxi-and-esx), this is much easier than moving [from a single to multi-node CouchDB instance]({{< relref "hosting/4.x/data-migration" >}}). +When thousands of users are simultaneously trying to synchronize with the CHT, the load can overwhelm CouchDB. As discovered [through extensive research](https://forum.communityhealthtoolkit.org/t/how-we-tested-scalability-of-cht-infrastructure/1532) and [large production deployments](https://github.com/medic/cht-core/issues/8324#issuecomment-1691411542), administrators will start to see errors in their logs and end users will complain of slow sync times. Before moving to more CouchDB nodes, administrators should consider adding more RAM and CPU to the single server where the CHT is hosted. This applies to both CHT 3.x and CHT 4.x. Given the ease of allocating more resources, presumably in virtualized environment like [EC2](https://aws.amazon.com/ec2/), [Proxmox](https://www.proxmox.com/en/) or [ESXi](https://www.vmware.com/products/cloud-infrastructure/esxi-and-esx), this is much easier than moving [from a single to multi-node CouchDB instance]({{< relref "hosting/4.x/data-migration" >}}). Here we see a normal deployment following the bare minimum [hosting requirements]({{< relref "hosting/requirements" >}}) for the CHT. We'll call this a "short" deployment because it is not yet vertically scaled: