App-V for Windows capacity planning
Applies to: Windows 10, Windows 11, Windows Server 2016
The following recommendations can be used as a baseline to help determine capacity planning information that is appropriate to your organization's App-V infrastructure.
Important
Use the information in this section only as a general guide for planning your App-V deployment. Your system capacity requirements will depend on the specific details of your hardware and application environment. Additionally, the performance numbers displayed in this document are examples and your results may vary.
Determine the project scope
Before you design the App-V infrastructure, determining which applications will be available virtually, and also identify the target users and their locations. This information will determine what type of App-V infrastructure your project should implement. You should base your decisions about your project's scope on your organization's specific needs.
| Task | More information |
|---|---|
| Determine application scope | The App-V infrastructure can be set up in different ways depending on which applications you want to virtualize. This customization in set up means your first task is to define which applications you want to virtualize. |
| Determine location scope | "Location scope" refers to the physical locations where you plan to run the virtualized applications (for example, enterprise-wide or a specific geographic location). It can also refer to the user population that will run the virtual applications (for example, a single department). You should obtain a network map that includes the connection paths, the available bandwidth for each location, the number of users using virtualized applications, and the WAN link speed. |
Determine which App-V infrastructure is required
You can also manage your App-V environment using an electronic software distribution (ESD) solution such as Microsoft Systems Center Configuration Manager. For more information, see How to deploy App-V packages using electronic software distribution.
Standalone model—The standalone model allows virtual applications to be Windows Installer-enabled for distribution without streaming. App-V in Standalone mode only needs the sequencer and the client; no extra components are required. Applications are prepared for virtualization using a process called sequencing. For more information, see Planning for the App-V Sequencer and Client deployment. The standalone model is recommended for the following scenarios:
- When there are disconnected remote users who can't connect to the App-V infrastructure.
- When you're running a software management system, such as Configuration Manager.
- When network bandwidth limitations inhibit electronic software distribution.
Full infrastructure model—The full infrastructure model provides for software distribution, management, and reporting capabilities; it also includes the streaming of applications across the network. The App-V full infrastructure model consists of one or more App-V management servers that can be used to publish applications to all clients. Publishing places the virtual application icons and shortcuts on the target computer. It can also stream applications to local users. For more information about how to install the management server, see Planning for App-V Server deployment. The full infrastructure model is recommended for the following scenarios:
- When you want to use the Management Server to publish the application to target computers.
- For rapid provisioning of applications to target computers.
- When you want to use App-V reporting.
Important
The App-V full infrastructure model requires Microsoft SQL Server to store configuration data. For more information, see App-V supported configurations.
End-to-end server sizing guidance
The following section describes end-to-end App-V sizing and planning. For more specific information, refer to the subsequent sections.
Note
Round trip response time on the client is the time taken by the computer running the App-V client to receive a successful notification from the publishing server. Round trip response time on the publishing server is the time taken by the computer running the publishing server to receive a successful package metadata update from the management server.
- 20,000 clients can target a single publishing server to obtain the package refreshes in an acceptable round trip time (<3 seconds).
- A single management server can support up to 50 publishing servers for package metadata refreshes in an acceptable round trip time (<5 seconds).
App-V Management Server capacity planning recommendations
The App-V publishing servers require the management server for package refresh requests and package refresh responses. The management server then sends the information to the management database to retrieve information. For more information about App-V management server supported configurations, see App-V supported configurations.
Note
The default refresh time on the App-V publishing server is ten minutes.
When multiple simultaneous publishing servers contact a single management server for package metadata refreshes, the following three factors will influence the publishing server's round-trip response time:
- The number of publishing servers making simultaneous requests.
- The number of connection groups configured on the management server.
- The number of access groups configured on the management server.
The following table describes each factor that impacts round-trip time in more detail.
Note
Round trip response time is the time taken by the computer running the App-V publishing server to receive a successful package metadata update from the management server.
| Factors impacting round-trip response time | Description |
|---|---|
| The number of publishing servers simultaneously requesting package metadata refreshes. | A single management server can respond to up to 320 publishing servers simultaneously requesting publishing metadata. For example, in a case with 30 publishing servers simultaneously requesting publishing metadata, the round-trip response time is about 40 seconds, while for less than 50 servers it's less than 5 seconds. From 50 to 320 publishing servers, response team increases linearly (approximately 2×). |
| The number of connection groups configured on the management server. | For up to 100 connection groups, there's no significant change in the round-trip response time on the publishing server. For 100-400 connection groups, there's a minor linear increase in the round-trip response time. |
| The number of access groups configured on the management server. | For up to 40 access groups, there's a linear (approximately 3×) increase in the round-trip response time on the publishing server. |
The following table displays sample values for each of the previous factors. In each variation, 120 packages are refreshed from the App-V management server.
| Scenario | Variation | Number of connection groups | Number of access groups | Number of publishing servers | Network connection type | Round-trip response time (seconds) | Management server CPU utilization |
|---|---|---|---|---|---|---|---|
| Publishing servers contact management server for publishing metadata at same time | Number of publishing servers. | 0 0 0 0 0 0 |
1 1 1 1 1 1 |
50 100 200 300 315 320 |
LAN | 5 10 19 32 30 37 |
17 17 17 15 17 15 |
| Publishing metadata contains connection groups | Number of connection groups | 10 20 100 150 300 400 |
1 1 1 1 1 1 |
100 100 100 100 100 100 |
LAN | 10 11 11 16 22 25 |
17 19 22 19 20 20 |
| Publishing metadata contains access groups | Number of access groups | 0 0 0 0 |
1 10 20 40 |
100 100 100 100 |
LAN | 10 43 153 535 |
17 26 24 24 |
The CPU utilization of the computer running the management server is around 25% irrespective of the number of publishing servers targeting it. The Microsoft SQL Server database transactions/sec, batch requests/sec and user connections are identical irrespective of the number of publishing servers. For example, transactions/sec is approximately 30, batch requests approximately 200, and user connects approximately six.
Through a geographically distributed deployment, where the management server and publishing servers utilize a slow link network between them, the round-trip response time on the publishing servers is within acceptable time limits (<5 seconds), even for 100 simultaneous requests on a single management server.
| Scenario | Variation | Number of connection groups | Number of access groups | Number of publishing servers | Network connection type | Round-trip response time (seconds) | Management server CPU utilization (in %) |
|---|---|---|---|---|---|---|---|
| Network connection between the publishing server and management server | 1.5 Mbps Slow link Network | 0 0 |
1 1 |
50 100 |
1.5 Mbps Cable DSL | 4 5 |
1 2 |
| Network connection between the publishing server and management server | LAN/WiFi Network | 0 0 |
1 1 |
100 200 |
WiFi | 11 20 |
15 17 |
Whether the management server and publishing servers are connected over a slow link network, or a high speed network, the management server can handle approximately 15,000 package refresh requests in 30 minutes.
App-V Reporting Server capacity planning recommendations
App-V clients send reporting data to the reporting server. The reporting server then records the information in the Microsoft SQL Server database and returns a successful notification back to the computer running App-V client. For more information about the App-V Reporting Server's supported configurations, see App-V supported configurations.
Note
Round-trip response time is the time taken by the computer running the App-V client to send the reporting information to the reporting server and receive a successful notification from the reporting server.
| Scenario | Summary |
|---|---|
| Multiple App-V clients send reporting information to the reporting server simultaneously. | Round-trip response time from the reporting server is 2.6 seconds for 500 clients. Round-trip response time from the reporting server is 5.65 seconds for 1000 clients. Round-trip response time increases linearly depending on number of clients. |
| Requests per second processed by the reporting server. | A single reporting server and a single database can process a maximum of 139 requests per second. The average is 121 requests/second. With the help of two reporting servers that report to the same Microsoft SQL Server database, the average requests/second, like a single reporting server, is about 127, with a max of 278 requests/second. A single reporting server can process 500 concurrent/active connections. A single reporting server can process a maximum 1,500 concurrent connections. |
| Reporting database. | Lock contention on the computer running Microsoft SQL Server is the limiting factor for requests/second. Throughput and response time are independent of database size. |
Calculating random delay
The random delay specifies the maximum delay (in minutes) for data to be sent to the reporting server. When the scheduled task is started, the client generates a random delay between 0 and ReportingRandomDelay and will wait the specified duration before sending data.
Random delay = 4 × number of clients/average requests per second.
Example: Random delay for 500 clients with 120 requests per second is 4 × 500/120 = about 17 minutes.
App-V publishing server capacity planning recommendations
Computers running the App-V client connect to the App-V publishing server to send a publishing refresh request and receive a response. Round trip response time is measured on the computer running the App-V client, while processor time is measured on the publishing server. For more information about App-V Publishing Server supported configurations, see App-V supported configurations.
Important
The following list displays the main factors to consider when setting up the App-V publishing server:
- The number of clients connecting simultaneously to a single publishing server.
- The number of packages in each refresh.
- The available network bandwidth in your environment between the client and the App-V publishing server.
| Scenario | Summary |
|---|---|
| Multiple App-V clients connect to a single publishing server simultaneously. | A publishing server running dual core processors can respond to at most 5000 clients requesting a refresh simultaneously. For 5,000-10,000 clients, the publishing server requires a minimum quad core. For 10,000-20,000 clients, the publishing server should have dual quad cores for more efficient response times. A publishing server with a quad core can refresh up to 10,000 packages within three seconds. (Supports 10,000 simultaneous clients.) |
| Number of packages in each refresh. | Increasing number of packages will increase response time by about 40% (up to 1,000 packages). |
| Network between the App-V client and the publishing server. | Across a slow network (1.5-Mbps bandwidth), there's a 97% increase in response time compared to LAN (up to 1,000 users). |
Note
The publishing server CPU usage is always high during the time interval when it must process simultaneous requests (>90% in most cases). The publishing server can handle about 1,500 client requests in one second.
| Scenario | Variation | Number of App-V clients | Number of packages | Processor configuration on publishing server | Network connection type | App-V client round-trip time (in seconds) | Publishing server CPU utilization (in %) |
|---|---|---|---|---|---|---|---|
| App-V client sends publishing refresh request and receives response, each request containing 120 packages | Number of clients | 100 1,000 5,000 10,000 |
120 120 120 120 |
Dual Core Dual Core Quad Core Quad Core |
LAN | 1 2 2 3 |
100 99 89 77 |
| Multiple packages in each refresh. | Number of packages | 1,000 1,000 |
500 1,000 |
Quad Core | LAN | 2 3 |
92 91 |
| Network between client and publishing server. | 1.5 Mbps Slow link network | 100 500 1,000 |
120 120 120 |
Quad Core | 1.5-Mbps intra-continental network | 3 10 (0.2% failure rate) 7 (1% failure rate) |
App-V streaming capacity planning recommendations
Computers running the App-V client stream the virtual application package from the streaming server. Round trip response time is measured on the computer running the App-V client, and is the time taken to stream the entire package.
Important
The following list identifies the main factors to consider when setting up the App-V streaming server:
- The number of clients streaming application packages simultaneously from a single streaming server.
- The size of the package being streamed.
- The available network bandwidth in your environment between the client and the streaming server.
| Scenario | Summary |
|---|---|
| Multiple App-V clients stream applications from a single streaming server simultaneously. | If the number of clients simultaneously streaming from the same server increases, there's a linear relationship with the package download/streaming time. |
| Size of the package being streamed. | The package size has a significant impact on the streaming/download time only for larger packages with a size of about 1 GB. For package sizes ranging from 3 MB to 100 MB, the streaming time ranges from 20 seconds to 100 seconds, with 100 simultaneous clients. |
| Network between the App-V client and the streaming server. | Across a slow network (1.5-Mbps bandwidth), there's a 70-80% increase in response time compared to LAN (up to 100 users). |
The following table displays sample values for each of the factors in the previous list:
| Scenario | Variation | Number of App-V clients | Size of each package | Network connection type | Round-trip time on the App-V client (in seconds) |
|---|---|---|---|---|---|
| Multiple App-V clients streaming virtual application packages from a streaming server. | Number of clients. | 100 200 1,000 100 200 1,000 |
3.5 MB 3.5 MB 3.5 MB 5 MB 5 MB 5 MB |
LAN | 29 39 391 35 68 461 |
| Size of each package being streamed. | Size of each package. | 100 200 100 200 |
21 MB 21 MB 109 MB 109 MB |
LAN | 33 83 100 160 |
| Network connection between client and App-V streaming server. | 1.5 Mbps Slow link network. | 100 100 |
3.5 MB 5 MB |
1.5-Mbps intra-continental network | 102 121 |
Each App-V streaming server should be able to handle a minimum of 200 clients concurrently streaming virtualized applications.
Note
The actual time to it will take to stream is determined primarily by the number of clients streaming simultaneously, number of packages, package size, the server's network activity, and network conditions.
For example, an average user can stream a 100-MB package in less than 2 minutes, when 100 simultaneous clients are streaming from the server. However, a package of size 1 GB could take up to 30 minutes. In most real-world environments, streaming demand isn't uniformly distributed, you'll need to understand the approximate peak streaming requirements present in your environment to properly size the number of required streaming servers.
The number of clients a streaming server can support can be increased and the peak streaming requirements reduced if you pre-cache your applications. You can also increase the number of clients a streaming server can support by using on-demand streaming delivery and stream optimized packages.
Combining App-V server roles
Discounting scaling and fault-tolerance requirements, the minimum number of servers that a location with Active Directory connectivity needs to function is 1. This server will host the management server, management server service, and Microsoft SQL Server roles. This coverage means that you can arrange server roles in any combination you like, as they don't conflict with one another.
Notwithstanding scaling requirements, the minimum number of servers that a fault-tolerant implementation needs to function is four. The management server and Microsoft SQL Server roles support placement in fault-tolerant configurations. The management server service can be combined with any of the roles, but remains a single point of failure.
Although there are many fault-tolerance strategies and technologies you can use, not all are applicable to a given service. Additionally, if App-V roles are combined, the resulting incompatibilities could cause certain fault-tolerance options to stop working.