Difference between revisions of "Hardware Sizing"
| (6 intermediate revisions by the same user not shown) | |||
| Line 11: | Line 11: | ||
! ID !! Topology !! EC2 instance type !! EC2 instance type (app server) !! EC2 instance type (DB server) !! Optimal concurrent users !! Architecture !! Bandwidth !! Hardware equivalence (single server) !! Hardware equivalence (app server) !! Hardware equivalence (DB server) | ! ID !! Topology !! EC2 instance type !! EC2 instance type (app server) !! EC2 instance type (DB server) !! Optimal concurrent users !! Architecture !! Bandwidth !! Hardware equivalence (single server) !! Hardware equivalence (app server) !! Hardware equivalence (DB server) | ||
|- | |- | ||
| − | | 1. || Single || c3.xlarge || - || - || 25 || 64-bit (x86_64) || 10 Mbps || | + | | 1. || Single || c3.xlarge || - || - || 25 || 64-bit (x86_64) || 10 Mbps || 8 GiB of memory, 4 vCPUs, 320 GB of SSD-based local instance storage + Amazon EBS volumes as per need || - || - |
|- | |- | ||
| − | | 2. || Single || c3.2xlarge || - || - || 50 || | + | | 2. || Single || c3.2xlarge || - || - || 50 || 64-bit (x86_64) || 10 Mbps || 15 GiB of memory, 8 vCPUs, 320 GB of SSD-based local instance storage + Amazon EBS volumes as per need || - || - |
|- | |- | ||
| − | | 3. || Dual || - || c3.2xlarge || c3.2xlarge || 100 || | + | | 3. || Dual || - || c3.2xlarge || c3.2xlarge || 100 || 64-bit (x86_64) || 20 Mbps || - || 15 GiB of memory, 8 vCPUs, 320 GB of SSD-based local instance storage || 15 GiB of memory, 8 vCPUs, 320 GB of SSD-based local instance storage + Amazon EBS volumes as per need |
|- | |- | ||
| − | | 4. || Dual || - || c3.4xlarge || c3.4xlarge || 200 || | + | | 4. || Dual || - || c3.4xlarge || c3.4xlarge || 200 || 64-bit (x86_64) || 30 Mbps || - || 30 GiB of memory, 16 vCPUs, 320 GB of SSD-based local instance storage || 30 GiB of memory, 16 vCPUs, 320 GB of SSD-based local instance storage + Amazon EBS volumes as per need |
|} | |} | ||
==Important Sizing Notes== | ==Important Sizing Notes== | ||
| + | This data has been estimated taking averaged information from sources mentioned in Introduction into account. SmartHCM strongly recommends to test customer installations before going live. The proposed approach is to do manual load testing: when SmartHCM is installed, configured and adjusted for the customer, so ready to go, - just do a test run with all customer users emulating normal day-to-day operations and observe the performance (taking notes about users feedback and monitoring main server parameters: CPU load, memory usage). | ||
| + | |||
| + | For "on premise" installations it is recommended to be more conservative and apply a security factor (looking at the next level hardware configurations or more CPU speed, more RAM and the faster disk) so that we all can be more confident that the hardware will be able to cope with the requirements. | ||
Latest revision as of 07:02, 14 September 2021
Introduction
A sizing is an approximation of the hardware resources required to support a specific software implementation, in this case SmartHCM. This document sets main foundations towards sizing the hardware required to run SmartHCM. SmartHCM has experience managing internal product installations on the basic instance types provided by Amazon EC2: m1.small, c1.medium and m1.large. We know the results that these instances can provide us, both in terms of performance and scalability. At the same time SmartHCM embraces experience of our customers running product on physical hardware and also using virtualization. In addition to this SmartHCM does performance tests for particular product usage scenarios. These three inputs has allowed us to write a table comparing the hardware resources needed to support particular number of concurrent users.
Sizing Table
| ID | Topology | EC2 instance type | EC2 instance type (app server) | EC2 instance type (DB server) | Optimal concurrent users | Architecture | Bandwidth | Hardware equivalence (single server) | Hardware equivalence (app server) | Hardware equivalence (DB server) |
|---|---|---|---|---|---|---|---|---|---|---|
| 1. | Single | c3.xlarge | - | - | 25 | 64-bit (x86_64) | 10 Mbps | 8 GiB of memory, 4 vCPUs, 320 GB of SSD-based local instance storage + Amazon EBS volumes as per need | - | - |
| 2. | Single | c3.2xlarge | - | - | 50 | 64-bit (x86_64) | 10 Mbps | 15 GiB of memory, 8 vCPUs, 320 GB of SSD-based local instance storage + Amazon EBS volumes as per need | - | - |
| 3. | Dual | - | c3.2xlarge | c3.2xlarge | 100 | 64-bit (x86_64) | 20 Mbps | - | 15 GiB of memory, 8 vCPUs, 320 GB of SSD-based local instance storage | 15 GiB of memory, 8 vCPUs, 320 GB of SSD-based local instance storage + Amazon EBS volumes as per need |
| 4. | Dual | - | c3.4xlarge | c3.4xlarge | 200 | 64-bit (x86_64) | 30 Mbps | - | 30 GiB of memory, 16 vCPUs, 320 GB of SSD-based local instance storage | 30 GiB of memory, 16 vCPUs, 320 GB of SSD-based local instance storage + Amazon EBS volumes as per need |
Important Sizing Notes
This data has been estimated taking averaged information from sources mentioned in Introduction into account. SmartHCM strongly recommends to test customer installations before going live. The proposed approach is to do manual load testing: when SmartHCM is installed, configured and adjusted for the customer, so ready to go, - just do a test run with all customer users emulating normal day-to-day operations and observe the performance (taking notes about users feedback and monitoring main server parameters: CPU load, memory usage).
For "on premise" installations it is recommended to be more conservative and apply a security factor (looking at the next level hardware configurations or more CPU speed, more RAM and the faster disk) so that we all can be more confident that the hardware will be able to cope with the requirements.
