Overview
ProcessMaker is a flexible web-based application that is designed to accommodate both small-scale implementation in a single department and large-scale application in organizations with thousands of users. Large-scale execution, however, requires careful planning and an adequate setup to accommodate the processing, bandwidth and storage needs of the system.
The following document describes how to appropriately size an on-premise ProcessMaker 3 environment for different use cases (development vs production, etc). After the sizing guidelines are listed, best practices and suggested stack configurations are also detailed.
General Environment Sizing Notes
ProcessMaker is a data intensive platform. As such, the majority of the workload is usually dependent on the database environment. A properly tuned database environment is an absolute requirement for a production environment in ProcessMaker. Many of the sizings detailed will be focused on data storage.
ProcessMaker is used in various enterprise environments with different use cases. The Best Practices described below is not a one size fit all solution. Please take your use cases into account and use your best judgement to determine the best architecture solution.
Web Application Server Layer Sizing and Deployment
The key to any server sizing project is to determine and understand the guidelines and types of workloads involved when running ProcessMaker on a large-scale. Read the following guidelines below to help accurately evaluate your system requirements:
Process Capability and Memory
- Estimate the number of cases to be created per day. The number of processes created in a day has an effect on the performance of ProcessMaker, which is why its important to have an estimate before sizing the server.
- Consider the total number of nominal users that are expected to be using ProcessMaker.
- Use a web application server tuned for medium CPU and memory capacity.
- Depending on the level of redundancy security the customer requires, the production web application server cluster should at LEAST support one server being unavailable. This means the other remaining servers should have surplus CPU/RAM capacity to handle the extra load if this occurs.
For example, if there are two production servers, ideally 50% of one server's capacity should handle 100% of the volume at peak, at a minimum. - Consider one CPU core (or hyper-thread) to every 4 gigabytes of memory.
- For example, for a web application server that has 64GB of memory, a 16 thread/core processing environment is suggested.
- Assume a maximum allowed size per server to be 128GB of memory, with a minimum of 32 thread processing.
- Assume a minimum base frequency of 2.4GHz
- Consider dedicating 128MB for one active user at a time.
- This value might change depending on memory requirements for certain processes, etc.
- This value is based on the memory_limit in PHP's configuration file and should also account for the overhead web server memory requirements.
- For the total amount of users, ensure that there is a buffer that allows for 30% spikes at any time.
- For the Memcache Server, consider that PHP 7.1 and later is compatible with PECL - igbinary 2.0.2. For a detailed compatibility, see Changelog for igbinary.
Network Speed
- These servers should have gigabit network interfaces and should be local to the shared resources of the load balancer and dependencies (file server, databases and caching). Ensure that your router and Internet bandwidth supports your expected incoming and outgoing traffic.
I/O Performance
- These servers are dedicated to ProcessMaker and share no other responsibilities.
- For production environments, there should be a minimum of two servers to balance traffic and provide redundancy (if one server is out of commission).
- No redundancy is required at the hard-drive level.
- Application files are stored on the file server mounts (NFS).s
- Customer assumes responsibility for system logging and rotation.
- Customer assumes responsibility for operating system and web server maintenance.
- SSDs are not required, in fact, platter disks are recommended for system file logging.
Calculating Hardware Requirements
The sections below provide guidance on how to calculate hardware requirements, taking various considerations into account.
Total Memory Required Calculation
Where:
- pu: Peak number of users.
- mmpu: Maximum amount of memory in megabytes per user.
- 1.3: Allows for 30% growth/spikes at peak.
- tm: Total memory required for this environment.
Total Minimum Servers Required Calculation
Where:
- tm: Total memory required.
- rl: The redundancy level specified (a minimum of 2). There is always a minimum level of redundancy required.
- mps: Maximum amount of memory per server the customer can acquire (a maximum of 128GB is recommended).
- sc: Total server count. Round up sc to ensure an adequate number of servers.
- mw: Minimum number of servers required.
Memory Per Server Calculation
Where:
- tm: Total memory required.
- rl: Redundancy level required by customer.
- ms: Minimum number of servers required.
- mmps: Minimum amount of memory required per server.
- mps: The value of mmps rounded up to a whole number divisible by 8.
CPU Core/Thread Per Server Minimum
- mps: Memory per server.
- cps: Number of cores/threads per server.
Examples
Widget Co.
Widget Co. has an estimated 200 simultaneous users at their peak time. They've stated they can only support servers with a total memory of 16GB. They request that they have a redundancy level of 2 (half of their fleet could be down at any time). Memory per user will be 128MB (default).
| Parameter Levels | Calculation | Result |
|---|---|---|
| Memory Calculation: | (200 * 128 * 1.3) / 1024 = 32.5 GB | 32.5 GB |
| Server Count Calculation: | (32.5 * 2) / 16 = 4.0625 > 2 = 4.06 | 4 servers. |
| Minimum Memory per server: | (32.5 * 2) / 5 = 13 rounded up to a whole number divisible by 8 = 16 GB | 16 GB per server. |
| CPU Cores per server: | 16 / 4 = 4 | 4 cores |
| Summary: Widget Co. needs four web servers, with 16GB of memory per server. Each server should have 4 cores or threads supported. | ||
Example Inc.
Example Inc. has an estimated 2000 simultaneous users at their peak time. They've instructed that the maximum amount of memory they want in each server is 64GB. They also want a redundancy level of 3 (they want a third of their fleet to be able to handle the entirety of their load). Memory per user will be 128MB (default).
| Parameter Levels | Calculation | Result |
|---|---|---|
| Memory Calculation: | (2000 * 128 * 1.3) / 1024 = 325 GB | 325 GB |
| Server Count Calculation: | (325 * 3) / 64 = 15.234375 > 2 = 16 | 16 webservers |
| Minimum Memory per server: | (325 * 2) / 16 = 40.625 rounded up to a whole number divisible by 8 = 48 GB | 48 GB per server |
| CPU Cores per server: | 48 / 4 = 12 | 12 cores |
| Summary: Widget Co. needs 16 web servers, with 48GB of memory per server. Each server should have 12 cores or threads supported. | ||
