Product Documentation

Planning for Applications and Server Loads

Oct 09, 2015

Before you can determine how many servers you need in your farm and on which servers to install applications, decide which applications you want to deliver and how you want to deliver them.

Consider these factors when defining your farm’s hardware and operating system configuration:
  • Can I run the applications? Citrix recommends testing non-Vista-compliant applications before you publish them on your farm. Some non-Vista-compliant applications run using the Application Compatibility feature.
  • How many users do I anticipate will want to connect to each application during peak and off-peak hours? Do I need to allocate servers for load balancing?
  • Will users be accessing certain applications frequently? Do I want to publish all of these applications on the same server to facilitate session sharing and reduce the number of connections to a server? If you want to use session sharing, you might also want users to run applications in seamless windows. .
  • Will my organization need to provide proof of regulatory compliance for certain applications? Will any applications undergo a security audit? If you intend to use SmartAuditor to record sessions on these servers, install the SmartAuditor agent on these servers. In addition, make sure the servers have sufficient system resources to ensure adequate performance.
  • Will any of my applications be graphically intensive? If so, consider using the XenApp SpeedScreen, Memory Utilization Management, or CPU Utilization Management features as well as more robust hardware for sessions hosted on these servers.

Assessing Applications for XenApp Compatibility

Ensure applications are compatible with the server operating system and are multiuser compatible. Application compatibility drives the application delivery method (for example, accessed from the server, streamed to server, or streamed to client desktops).

Evaluate whether or not applications are compatible with multiuser environments and, if so, the application server’s scalability. Before testing applications for compatibility, investigate how the application works with Remote Desktop Services or XenApp. Remote Desktop Services-compliant and Windows Logo certified applications experience few, if any, issues compared with noncompliant applications.

Initial application compatibility testing typically involves publishing the application so that is installed and hosted on a server in a test farm and having multiple test users connect to it. Applications that function correctly should be tested for conflicts with other applications you want to install on the server and, then, scalability.

Applications that do not function correctly might not have been designed for multiuser, multiapplication environments. Applications not designed for these environments can conflict with other applications or have scalability or performance issues. Registry settings, attempts to share files or DLLs, requirements for the exclusive use of files or DLLs, or other functionality within an application can make it incompatible. You can resolve some application issues through streaming, using features like Virtual IP, or siloing the application.

After testing, if these solutions do not work, you might need to find and fix the root cause of the problem. To identify root applications issues, consider using tools like the Microsoft Application Compatibility Toolkit (ACT) or Microsoft’s Windows Sysinternals. Examples of common issues include:
  • .INI files that contain hard-coded file path names, database connection settings, and read/write file locking configurations that need to be reconfigured to prevent file conflicts.
  • Custom applications developed with hard-coded paths in the registry.
  • Applications that use the computer name or IP address for identification purposes. Because a server can run multiple instances of the application, all instances could use the same IP address or computer name, which can cause the application to fail.

When you find any of these hard-coded settings or other conflicts, document the setting in your farm design document. After you find resolutions to these issues, design your farm and test your design by creating a pilot test farm.