XenApp – Design Consideration – Part 3


In the part 1, we discussed about how to manage user / application specific configuration data for successful implementation of any application in XenApp world. That was one of the important parameter to be considered.

In this article we will discuss about how to minimize XenApp’s memory and CPU usage for less important activities so that user can have their share of CPU and memory most of the time.

In the client – server architecture as shown in the below diagram:

  • Clients will be installed on XenApp
  • Servers will be installed on the application server machine [non-XenApp]
  • Many clients will share same XenApp
  • Many servers will be installed on common application server machines.

In the below diagram, All client are installed on same XenApp machine. Client 1 and Client 3 are sharing same application server machine where their servers are installed. Client 2 and Client 4 have dedicated application server machines where their servers are installed. Users will access their client from Web ICA.

image

Now since all the clients are installed on the same XenApp and if these clients are heavy in terms of processing, with many users accessing these clients, this could eat up the available memory and CPU of XenApp.

Also, sometimes, because of less experienced developers, when they create the objects in the application, they forgot to free the memory space occupied by the object by deleting them when they go out of their scope. Sometimes developer assumes that the underlying programming language will take care the garbage collection. In such cases when users will access these clients, the unhandled objects might eat up the available memory for no reasonable activity. It would lead to the request denial by XenApp.

Mission of every administrator is to make XenApp running and available for users each and every time. Following recommendations could be helpful in achieving the above mission:

  • Thin client and thick server: In the client server architecture, if we design the application in such a way that maximum processing should be done on the application server side and client should act like input and output interface with minimum processing, so with high end application server machine, we can make XenApp available to maximum users all the time.
  • Programming language best practices: Developers should be aware of all the best practices and recommendations of the programming language they are using. They should use those function/methods that consume less memory and CPU. If they have created any object, they should kill it once they will be out of scope.

In the traditional way of deployment outside XenApp, the above recommendation might not show the big benefits but in the environment where several clients are installed on the same XenApp and many users are accessing them at the same time, the above recommendations will make the difference.

Advertisements

One thought on “XenApp – Design Consideration – Part 3

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s