AppSense Performance Manager – a simple configuration

I still get the odd email from people asking how to set up a simple Performance Manager configuration. It seems that Performance Manager tends to be the part of the Management Suite AppSense administrators are least likely to tinker with – particularly as a misconfigured setting could possibly adversely affect a lot of users on shared SBC systems like XenApp and RDS. However, you can use it to increase the user density on your systems, so it’s got to be worth at least trying to configure it!

In a nutshell, AppSense Performance Manager allows administrators to precisely manage the allocation and distribution of system resources such as CPU, memory and disk for users and applications. It includes automated application memory optimization to reduce page file usage and CPU thread throttling to control demand of resources to ensure efficient and smooth running of a system. Performance Manager also, in keeping with the hallmarks of the AppSense Management Suite, provides fine level granular management by allowing allocation of resources based on the state of the session, applications or desktop. Testing done recently using it showed that implementing AppSense Performance Manager on a VDI solution reduced overall CPU utilization by approximately 10%, and I’ve heard tell of instances where SBC environments increased their user density by up to 40%.

Performance Manager is markedly different to Environment Manager in that less is definitely more. You should only manage and restrict applications if there’s a definite need for it. Otherwise configuring it with some basic default settings should suffice. AppSense have done a good job of defining some best practice guidelines and providing a very simple basic configuration on their website – I am going to cover those areas quickly here and also run through an example of restricting a particular application for a particular AD group.

Basic configuration

The first part you should look at when creating your Performance Manager configuration is the Options area. Performance Manager, more than any other part of the Management Suite, is very sensitive to the configuration options defined here. AppSense recommend that unless you have an atypical environment (and let’s be clear here, we are talking about primarily SBC, which means mainly RDS and XenApp systems) that the Options section should be configured as shown below

Share factors should be enabled as these allow specific groups, users or applications to be allocated a larger “share” of the CPU resource. This is very handy for SBC systems.

Affinity and Reservations have more applicability on single-purpose systems such as IIS, SQL, etc. and therefore should be disabled unless these are the systems you are managing with this configuration. Whilst it seems unlikely that people would use Performance Manager agents on back-end systems such as these, I have seen it done in situations where there were performance issues affecting productivity. It just goes to show that Performance Manager’s application can be very far from the “expected” uses of the product.

Application memory limits deals with virtual memory and shouldn’t need to be enabled unless you specifically find an application with virtual memory issues. User memory control also deals with virtual memory usage and shouldn’t be enabled.

Physical memory management is very useful on SBC platforms. It provides significant benefits by “memory trimming” the working set of each process. It does cause an increase in paging, but in general this is outweighed by the performance gain.

Disk priority allocation shouldn’t be used on SBC platforms (I once saw it erroneously enabled on a XenApp 6 farm, and the logon time increased by a very noticeable amount!) It should only be applicable on desktop or laptop platforms, and even then it should be monitored closely.

Memory optimization is not recommended, unless you have a glut of old applications that may benefit from DLL rebasing. There’s also the possibility that the same optimization is being done by Citrix and/or Windows Server 2008 to consider. Generally it is only recommended to enable this feature when you have research specifically indicating you may benefit from it (the Optimizer Monitor may be helpful in this situation).

Finally, Thread Throttling should be enabled for both user and system processes. On any Windows platform, this should provide an appreciable benefit. The recommended settings for Thread Throttling are shown below – you can tweak this if you so require.

Once you’ve got these options configured, you will have the basis of a simple configuration that should hopefully be able to make a difference even in this basic format. One thing you may want to additionally do is go to the <Other Users> <Any Application> section and enable memory trimming on the Memory tab, by checking the Enable and Trim Process Memory boxes (shown below).

Now we could stop here and say this is a good base for any Performance Manager configuration, but frankly this would be only going as far as AppSense’s best practice documents go, so it would be prudent to try and add a little bit more value to this post 🙂

Adding application groups

When you’ve identified any applications that might need extra attention, you’ll need to add them into the console. Every environment has its own candidates but popular ones you will find cropping up are Internet Explorer, Java, and Outlook.

You add applications for specific management rules by right-clicking the Application Groups container and choosing Add New. As always, adding a sensible name is a good starting point. You can then browse to a local or remote system and retrieve a list of installed applications/services and running processes to select the target process from a list, but it makes more sense to simply use the process name. If you don’t specify the full path, it ensures that the process will be managed appropriately no matter where it is launched from.

In the example below we have added Firefox as an Application Group, clicking Next and then Add will publish it to the list.

Adding target groups

Now, in this example we will only be looking to manage a particular application for a particular user group. Maybe a certain set of users work on a browser-based app that keeps monopolizing CPU and/or physical memory, so we want to restrict it. To add a group for management, we right-click the Resource Management section and choose Add Users/Groups | Select User/Group

You can browse the domain/computer for the required users or groups, or simply enter the name manually. We add our AD group and click OK, and it appears under the Resource Planning heading on the left.

Adding application groups to user groups

Next we right-click the user group we have added and choose Add Applications. We can select the application or application group that we have created. In this case, we will add Internet Explorer as we are looking to manage the performance of iexplore.exe for this particular AD group.

At this point we could add various Rules to change the behaviour of Performance Manager towards this application based on configurable factors such as windows position, session state, etc., but we are going to keep things simple and manage it with the Default Rule, which will apply at all times the process is running for this group.

Configuring actions for the application

We want to stop iexplore.exe from using up all of the available CPU resources. We will first go to the CPU section and enable the Limit for the application and set it to 10%. Note you can choose Hard or Soft limits. Soft limits only apply when the system is running under heavy load (i.e. the requested CPU time from all processes on the CPU exceeds 100%). Hard limits apply globally – which means the process is always limited to the set amount of CPU regardless of the server load. In this example we will set a Hard limit.

We also want to restrict the amount of memory it can use, so we will switch to the Memory tab and check the box to Enable this, which also automatically checks Trim Process Memory. We want to set a Maximum limit of 90MB so we check the box and set the limit to 90. You will notice you can also set a Minimum, if you wish to ensure a process always uses a certain amount of memory. There is also the option here for Hard and Soft limits, we have chosen Hard again in this example.

So now, when users from the specified AD group run the Internet Explorer process on my XenApp or RDS system, the Performance Manager agent will limit them to using 10% of the CPU and 90MB of memory, hopefully curtailing the performance issues that have arisen from this unreliable browser-based application the group uses.

That covers a very simple setup of Performance Manager, and how to add groups and applications for specific attention. Don’t forget, though, that you should only specifically restrict applications if their performance is shown to be affecting the stability or performance of sessions. Don’t just restrict them “because you can”. Even with only the global Options configured as shown above PM should still positively increase the performance of your systems, so remember that you should only get more precise if absolutely necessary – and don’t forget to thoroughly test all of your application functionality on a test group before sending it fully live!

Config available – the configuration we used in this post is available for download here if anyone’s interested, obviously the group name will not be valid in a different environment 🙂

Share

Want to partner with us?