From 7193719de0e01fbe5d5c4c5e7d9c2c9b030879db Mon Sep 17 00:00:00 2001 From: Samuel Okwalinga <70289309+sookwalinga@users.noreply.github.com> Date: Thu, 21 Dec 2023 11:56:09 +0300 Subject: [PATCH] fix: Update vertical-vs-horizontal.md (#1256) Fix grammatical errors. --- content/en/apps/guides/hosting/vertical-vs-horizontal.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/en/apps/guides/hosting/vertical-vs-horizontal.md b/content/en/apps/guides/hosting/vertical-vs-horizontal.md index 4929319da..7ec6df318 100644 --- a/content/en/apps/guides/hosting/vertical-vs-horizontal.md +++ b/content/en/apps/guides/hosting/vertical-vs-horizontal.md @@ -20,7 +20,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 easy 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 to [from a single to multi-node CouchDB instance]({{< relref "apps/guides/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/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 "apps/guides/hosting/4.x/data-migration" >}}). Here we see a normal deployment following the bare minimum [hosting requirements]({{< relref "apps/guides/hosting/requirements" >}}) for the CHT. We'll call this a "short" deployment because it is not yet vertically scaled: