Skip to content

Commit

Permalink
fix: Update vertical-vs-horizontal.md (#1256)
Browse files Browse the repository at this point in the history
Fix grammatical errors.
  • Loading branch information
sookwalinga authored Dec 21, 2023
1 parent 182f830 commit 7193719
Showing 1 changed file with 1 addition and 1 deletion.
2 changes: 1 addition & 1 deletion content/en/apps/guides/hosting/vertical-vs-horizontal.md
Original file line number Diff line number Diff line change
Expand Up @@ -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:

Expand Down

0 comments on commit 7193719

Please sign in to comment.