Fair-Sharing CPU usage on Citrix XenApp to ensure Quality of Service and Faster Response Times (With AppSense Performance Manager)

July 23, 2009

The Server Based Computing (SBC) such as Microsoft Terminal Server and Citrix XenApp model offers many unique challenges for both architects and administrators. There are concerns of security, availability of resources, performance and the costs of hardware, licensing and ongoing management. Due primarily to opportunities for cost reduction in hardware purchases however, server consolidation through ‘optimizing performance’ has been the main area addressed. Fewer servers also result in lower licensing costs, lower maintenance overhead, and reduced electricity and cooling costs. However, it has now become apparent the real issue with performance is not just financial, but one of user experience. There is an ongoing tradeoff betweenensuring users receive a consistent ‘end-user experience’ while maintaining the minimum amount of hardware. 

 

Before considering CPU usage, management and optimization, it is first necessary to clarify CPU usage. When a figure such as 60% CPU usage is quoted, what is actually meant is the CPU is being utilized at 100% for 60% of the time. This shows a high CPU value is actually an efficient use of resource, rather than a problem.

 

A CPU utilization of 100%, while considered a problem by many, actually means maximum use is being made of this resource, and therefore achieving maximum return on investment. Problems occur when requests exceed 100% CPU utilization, whereby resource contention and bottlenecks are formed – although, this can be solved by efficiently allocating the resource between the users and running applications.

AppSense Performance Manager is able to control CPU usage in many ways, and may be used to not only resolve CPU usage issues, but also to ensure CPU resource to mission critical applications and users.  In this post I want to cover one specific feature function within AppSense Performance Manager – Smart Scheduling, or sometimes known as CPU Fair Sharing.

Smart Scheduling
With Microsoft operating systems, during process initialization, a priority is assigned for the process to run under. Microsoft Windows 2003 has the following priorities:-
Realtime, High, Above Normal, Normal, Below Normal, Low.

A process which has a higher priority will be allocated CPU prior to a process with a lower priority. Most applications when launched are given a ‘normal’ priority. This means that these processes form a ‘queue’ for the CPU and will receive CPU time only when it is their turn. There are a few standard system processes which are assigned a higher priority, such as the ‘Windows Task Manager’ which is automatically assigned a ‘high’ priority. This ensures should the Task Manager process require CPU time it will be given it immediately.

A process may consume a maximum amount of CPU time, known as the quantum time. If the process does not require the full quantum time, for example if it requires further data, it is able to release the process prior to completion of the quantum time, thereby allowing another process access to CPU resource.

When an application Launches, there are many calls to the disk to access new data, and therefore the process consumes small parts of the quantum time. Processes which involve a large number of calculations, such as highly mathematical applications, tend to use all of the CPU quantum time and are therefore CPU intensive.  If the timeline of processes within the CPU are mapped out the problems become immediately apparent.

For example – Below, Process A is Microsoft Word launching; Process B is a resource intensive Microsoft Excel macro.

 

Blog1

Scenario 1:- Only Process A is running in this scenario, the application performs at full speed as it gets CPU resource when required and disk resource when required.

Blog2

Scenario 2:- Process A and Process B running. In this scenario it is evident that process A has been dramatically slowed down as there is a length of time where it is waiting for process B to relinquish the CPU. This can have dramatic effects on the responsiveness of the process, and obviously increases the time to wait. As process A and B both have equal priorities one process has to wait for the other to finish.

AppSense Performance Manager includes ‘smart scheduling’ technology that is able to share the CPU resource more efficiently between running applications. The priorities of the process are altered dynamically. The result being that processes requiring a small amount of CPU time tend to be given a higher priority than those which tend to monopolize the CPU.

Blog3

In this way the CPU time is divided equally amongst both processes ensuring that each has a share and no one process is hogging the CPU, causing others to wait. Process B receives much smaller chunks of CPU time but similarly its waiting time is also short, ensuring that the application appears responsive to the user, and therefore still falls within its time to wait. The effect of this process is greatly reduces the CPU queue length.

By interpolating between standard priorities, and dynamically adjusting the priority of each process, AppSense Performance Manager is able to ensure more efficient processor usage. More importantly, from a user perspective, no application is seen to “freeze”, ensuring application responsiveness falls within the acceptable ‘time to wait’ period.

Share Factors
In the above examples we assumed both process A and B are equally important and therefore require an equal use of resources. In most cases this is not a true representation of applications and users. Servers contain both mission critical applications and also users with varying degrees of ‘importance’. By implementing share factors within AppSense Performance Manager, these applications and/or users may be given a higher or lower share of CPU time.

If the process A is a mission critical process then it may be assigned a higher share factor. The effect of this is to raise the priority of the process so that it may have a longer CPU time before process A is given a higher priority.

Blog4

Here process B has been given a higher share factor resulting in process A waiting on process B. The difference now is the time process A has to wait is a value which is configurable by the Administrator. A further function of AppSense Performance Manager is the ability to apply application or system state control. An application may be defined as having a high share factor when in the foreground, a medium share factor when in the background, and a low share factor when minimized.

If we now look at things from a user point of view, the application they are currently working on will always be guaranteed to receive CPU time, and can therefore always be made to function within its required time to wait, hence “performing well”. Other processes continue to receive a share of CPU time ensuring that they also function. One key system state for SBC systems is the ‘disconnected’ state.

By assigning a relatively low priority to all other states we can ensure that users who disconnect from the server without logging out properly, do not continue to consume valuable CPU resource which is then made available to all other users.

In conclusion, Microsoft Windows operating systems go some way to addressing how applications make use of system resources, but it is clear that in situations of high resource usage, such as in SBC environments, they are challenged. AppSense Performance Manager addresses these shortcomings. It provides many methods of controlling critical system resources such as CPU, Memory (both physical and virtual) and Disk. It’s CPU scheduling algorithm ensures that even in times of maximum CPU usage the server remains responsive for each user and application. If necessary, weighting may be given to ensure minimum response times for mission critical applications and/ or users.


Citrix Session & Application Timeouts, a Great Solution

July 21, 2009

I had a great day on Tuesday. An AppSense client had an issue where their remote workers experienced their Citrix applications timing out on them.

After connecting, and using application 1, by the time they go to use application number 2, it had timed out, and when they try to restart it, Web Interface had timed out as well.

So the clients question was  “How can AppSense help me?!”.

Enter “ENVIRO-MAN” from the left of screen. All dressed in pretty green and looking surprisingly like the Environment Manager Product Manager :-)

“Your session timeouts do not scare me” he roared as he landed awkwardly on the photocopier, injuring his knee.

While “ENVIRO-MAN” proceeded to bore one of the office staff with stories about the mighty Blackpool Football Club, I decided to dig in and fix the problem.

Session Timeouts are controlled by a number of parameters – as examples, there are some per server settings based on type of connection (RDP or ICA) and some user based settings set in Active Directory.

However, if you require more granularity, that’s where AppSense Environment Manager lives…

By using a Group Policy Action (Set ADM Policy / Set ADMX Policy), I was able to load in the ADM settings from the “C:\Windows\inf” directory.  I then typed “session” into the filter, and up came the Terminal Server Session Timeout setting…  Magic :-)

By using EM Rules/Conditions I could now vary the Session timeouts based on IP address, Client Name, or even by integrating it into the results of Citrix AAC filters :-)

I demoed it to the client (they were blown away), thanked ENVIRO-MAN for his help and left to help the next client in need.

All in a good days work :-)


Enabling OFFLINE Personalization Support for SBC and VDI

July 2, 2009

One of the biggest problems faced with a server based computing or virtual desktop environment, is that of ensuring any user personalization settings made to the desktop or application set whilst on the SBC or VDI session, are then persisted and available to the user when the user goes offline and uses an external or roaming device such as a laptop.  This is then repeated in ensuring any personalization changes a user makes on an offline device are also replicated and present back on the SBC or VDI session.

AppSense Environment Manager’s solves this crucial problem by providing users with a ‘follow me’ personality, across all delivery mechanisms and devices.  AppSense Environment Manager’s unique Offline Mode ensures mobile users have access to the latest version of their personalization settings when not inside or connected to the corporate network.

The process behind this is relatively simple and utilizes a ‘local virtualization cache’ which resides on the end point device.  When a user is logged on to a managed computer, their personalization data is stored locally in the virtual cache on the endpoint device. By default, when the user logs off or shuts down the device, the cache is deleted, and recreated when they next log on.

To enable offline availability of the settings stored within the local virtualization cache, the AppSense Environment Manager Console provides an option for the administrator to specify, on a per-machine basis, that the user is working in offline mode and requires their cache to be permanently available on the device, thereby not deleting it at logoff or shut down.

The settings are now available to the user for the duration of their disconnected state, any further changes the user makes to their desktop or application set during this time are automatically captured, redirected from the local registry and file system, to the local virtualization cache.  Upon reconnection to the network, these new settings (the delta’s) are automatically synchronized back to a SQL database and are available to be streamed back into any other concurrent session.

As you may be aware, the personalization (profile) settings are only one half of the user personality, the other half being ‘policy’.  Policy remains on the end point device at all times, regardless of whether the managed computer has offline mode enabled or disabled.  Policy remains as it is part of the AppSense Environment Manager configuration, which resides on the endpoint device at all times to set up, maintain and self heal the environment.

If you would like any further information, please do ask.