Capacity Planning for Windows Azure Pack: Web Sites
Updated: June 6, 2014
Applies To: Windows Azure Pack
Servers: Physical or Virtual?
Windows Azure Pack: Web Sites roles can be installed on Windows Server 2012 R2 or Windows Server 2012. The server instances can be physical computers or virtual machines. If you use virtual machines, they can be on any VM provider. As the performance gap between virtual machines and physical hardware shrinks, the cost/performance advantage of virtual machines makes them more attractive.
Capacity Planning by Web Sites Server Role
The Web Sites Controller typically experiences low consumption of CPU, memory, and network resources. However, for High Availability, you should have two controllers. Two controllers is also the maximum number of controllers permitted. You can create the second Web Sites Controller by using PowerShell and command line scripts. For more information, see Provision a Second Web Sites Controller.
The Front End routes requests to Web Workers depending on Web Worker availability. For High Availability, you should have more than one Front End, and you can have more than two. For capacity planning purposes, consider that each core can handle approximately 100 requests per second. For information on adding additional Front End servers, see Scaling Windows Azure Pack: Web Sites for High Availability.
The Web Sites Management Server role handles Web Sites Management traffic by using the Windows Azure Pack Web Sites Service REST API. The Management Server role typically requires only about 4 GB RAM in a production environment. However, it may experience high CPU levels when many management tasks (such as web site creation) are performed. For High Availability, you should have more than one server assigned to this role, and at least two cores per server.
For information on adding additional Management Servers, see Provision Additional Management Servers.
The Publisher role may experience heavy CPU utilization if many tenants are publishing simultaneously. For High Availability, make more than one Publisher role available. For information on adding additional Publisher servers, see Scaling Windows Azure Pack: Web Sites for High Availability.
For the File Server role, you can use the Standalone file server for development and testing. For production purposes, you should use a pre-configured Windows File Server, or a pre-configured non-Windows file server.
The Standalone file server is included as part of the default Windows Azure Pack: Web Sites installation. The Standalone installation provisions the File Server role on a single machine, places ACLs for the appropriate accounts, and creates the necessary network shares.
In production environments, the File Server role experiences intensive disk I/O. Because it houses all of the content and application files for tenant web sites, you should pre-configure a Windows File Server, File Server Cluster, or a non-Windows file server, file server cluster, or NAS (Network Attached Storage) device for this role. For more information, see Pre-configure a Windows File Server Cluster or NAS device for Windows Azure Pack: Web Sites.
Windows Azure Pack: Web Sites relies on File Server Resource Manager (FSRM), which does not support scale-out file servers.
For High Availability, you should have at least four Web Worker Roles, two for Shared web site mode and two for Reserved web site mode. The Shared and Reserved web site modes provide different levels of service to tenants. Of course, if you have many customers using Reserved mode (which is resource intensive), or many customers running in shared mode, more Web Workers will be required.
When considering the number of Web Worker roles to provision, remember that after a subscriber has placed a Web Worker in Reserved mode, that Web Worker will no longer be available to subscribers in Shared mode. For this reason, installing Windows Azure Pack: Web Sites without a Shared Web Worker instance is an unsupported configuration.
To help you determine the number of Web Worker roles required, consider the following:
Memory - Memory is the most critical resource for a Web Worker role. Insufficient memory impacts web site performance when virtual memory is swapped from disk. Each server requires approximately 1.2 GB of RAM for the operating system; the RAM available above this threshold can be used to run web sites.
Percentage of active web sites - Based on observed production workloads, approximately 5 percent of web sites in a Web Site Cloud are typically active. However, the percentage of web sites that are active at any given moment can be significantly higher or lower. Assuming an "active web site" rate of 5 percent, the maximum number of web sites to place in a Web Site Cloud should be no more than 20 times the number of active web sites (5 x 20 = 100).
Average memory footprint - The average memory footprint for websites observed in production environments is about 70 MB. Based on this number, the amount of memory that should be allocated across all Web Worker role computers or VMs installed on a Web Site Cloud may be calculated as follows:
Number of Provisioned web sites * 70MB * 5% - (Number of Web Worker Roles * 1044 MB)
For example, if 5,000 web sites are provisioned on a Web Site Cloud that is running 10 Web Worker roles, then each Web Worker role computer or VM should be allocated 7060 MB of RAM determined as follows:
5,000 * 70 * .05 – (10 * 1044) = 7060 (=about 7 GB)
For information on how to add Web Worker instances, see Scaling Windows Azure Pack: Web Sites for High Availability.
Windows Azure Pack Web Sites Runtime SQL Server Database
Windows Azure Pack Web Site Cloud makes extensive use of SQL Server. For High Availability, follow these guidelines for allocating RAM, Disk, and CPU resources:
Memory - Because SQL Server performance is most dependent on available memory, allocate at least 4 GB of RAM to your SQL Server for every 30,000 sites that are provisioned. For most scenarios, SQL performance will benefit from additional memory, and SQL Server will use as much memory as you allocate to it.
Disk space - For every 10,000 sites that are provisioned, allocate at least 4 GB of disk space.
CPU Count - To determine the number of cores to allocate to your SQL Server computer, you can use the following criteria:
When Task Manager or Performance Monitor shows that the CPU usage of SQL Server service approaches 70%, allocate one additional core.
For additional measures that you take to increase the availability of your SQL Servers, see Configuring SQL Server for High Availability.