A new Flexera Community experience is coming on November 25th. Click here for more information.
What is the general rule for server specs - cpu/cores/memory - based on number of users?
I thought I had this documented or noted, but I'm not finding it in the current App Portal documentation or Helpnet.
‎May 01, 2019 02:24 PM
The Recommended Configuration page in the App Portal Installation Guide contains some guidance on hardware sizing. The sizing guidance there does not vary based on the number of users.
‎May 01, 2019 09:13 PM
As Chris states, the "official" supported configuration is posted in the product documentation on HelpNet and is independent of number of users/devices supported by App Portal.
With that said, within North America Services, we often hear customers express that cost is a big concern and wonder if that level of hardware is really necessary for smaller environments. As such, North America Services has developed slightly modified guidance for "recommended minimums" that's tiered based on the number of managed users/devices. You could use the T1 sizing for a Development/Lab environment (though performance can be noticeably slow) and then use the appropriate size tier for Production. Remember that these are minimums in cases where cost is a big concern, and better performance can often be realized by provisioning a higher tier.
Tier |
System Resource Requirements |
Example Implementation Size |
T1 |
Processor: 4 Cores Memory (RAM): 8 GB Storage (Hard Disk): OS Volume: 40 GB App Volume: 10 GB Database Data Volume: 15 GB Database Log Volume: 5 GB |
1 – 4,999 users/devices |
T2 |
Processor: 4 Cores Memory (RAM): 16 GB Storage (Hard Disk): OS Volume: 40 GB App Volume: 10 GB Database Data Volume: 30 GB Database Log Volume: 10 GB |
5,000 – 49,999 users/devices |
T3 |
Processor: 8 Cores Memory (RAM): 32 GB Storage (Hard Disk): OS Volume: 40 GB App Volume: 10 GB Database Data Volume: 60 GB Database Log Volume: 15 GB |
50,000 – 99,999 users/devices |
T4 |
Processor: 8 Cores Memory (RAM): 64 GB Storage (Hard Disk): OS Volume: 40 GB App Volume: 10 GB Database Data Volume: 240 GB Database Log Volume: 60 GB |
100,000 – 399,999 users/devices |
T5 |
Special/Custom |
400,000+ users/devices |
Please note that just provisioning the resource quantities listed here doesn’t guarantee any particular performance benchmark. Other things that impact performance are network and storage I/O. Often, these are the performance bottleneck, so things like the type of storage (DASD/SAN/NAS/fiber channel), the number of disks in a given storage volume, the type of disks (SSD vs. HDD), the disk volume configuration (RAID 0, 1, 5, 10) can have a significant impact. This is very commonly the problem in virtualized environments where disk volumes are being shared across multiple VM’s. Likewise, network I/O can be a huge bottleneck in VM environments where multiple guests share a single or small number of network interfaces on the host. Security configurations can also have a large impact. IIS security settings can hinder performance even when not blocking functionality fully. These are hard to detect. Same with software or hardware firewalls, which could cause actions to attempt multiple retries before giving up and moving on.
‎May 02, 2019 02:38 PM
The Recommended Configuration page in the App Portal Installation Guide contains some guidance on hardware sizing. The sizing guidance there does not vary based on the number of users.
‎May 01, 2019 09:13 PM
As Chris states, the "official" supported configuration is posted in the product documentation on HelpNet and is independent of number of users/devices supported by App Portal.
With that said, within North America Services, we often hear customers express that cost is a big concern and wonder if that level of hardware is really necessary for smaller environments. As such, North America Services has developed slightly modified guidance for "recommended minimums" that's tiered based on the number of managed users/devices. You could use the T1 sizing for a Development/Lab environment (though performance can be noticeably slow) and then use the appropriate size tier for Production. Remember that these are minimums in cases where cost is a big concern, and better performance can often be realized by provisioning a higher tier.
Tier |
System Resource Requirements |
Example Implementation Size |
T1 |
Processor: 4 Cores Memory (RAM): 8 GB Storage (Hard Disk): OS Volume: 40 GB App Volume: 10 GB Database Data Volume: 15 GB Database Log Volume: 5 GB |
1 – 4,999 users/devices |
T2 |
Processor: 4 Cores Memory (RAM): 16 GB Storage (Hard Disk): OS Volume: 40 GB App Volume: 10 GB Database Data Volume: 30 GB Database Log Volume: 10 GB |
5,000 – 49,999 users/devices |
T3 |
Processor: 8 Cores Memory (RAM): 32 GB Storage (Hard Disk): OS Volume: 40 GB App Volume: 10 GB Database Data Volume: 60 GB Database Log Volume: 15 GB |
50,000 – 99,999 users/devices |
T4 |
Processor: 8 Cores Memory (RAM): 64 GB Storage (Hard Disk): OS Volume: 40 GB App Volume: 10 GB Database Data Volume: 240 GB Database Log Volume: 60 GB |
100,000 – 399,999 users/devices |
T5 |
Special/Custom |
400,000+ users/devices |
Please note that just provisioning the resource quantities listed here doesn’t guarantee any particular performance benchmark. Other things that impact performance are network and storage I/O. Often, these are the performance bottleneck, so things like the type of storage (DASD/SAN/NAS/fiber channel), the number of disks in a given storage volume, the type of disks (SSD vs. HDD), the disk volume configuration (RAID 0, 1, 5, 10) can have a significant impact. This is very commonly the problem in virtualized environments where disk volumes are being shared across multiple VM’s. Likewise, network I/O can be a huge bottleneck in VM environments where multiple guests share a single or small number of network interfaces on the host. Security configurations can also have a large impact. IIS security settings can hinder performance even when not blocking functionality fully. These are hard to detect. Same with software or hardware firewalls, which could cause actions to attempt multiple retries before giving up and moving on.
‎May 02, 2019 02:38 PM