How-to: XenApp/RDS Sizing and Capacity Planning with uberAgent for Splunk
Do you know the maximum number of users each of your terminal servers can host with acceptable performance? You may have found out the hard way how many are too many – but how many are just right? Farm sizing and server capacity planning are typical tasks for consultants who often have a hard time fighting the peculiarities of perfmon and logman trying to get the data they need for their calculations. It can be so much easier at no additional cost. The 60 day Enterprise Trial version of Splunk in conjunction with an evaluation license of uberAgent give all the information you need in much less time. Here is how.
The Trial version of Splunk allows you to index 500 MB per day. That is enough to have uberAgent collect data from at least six XenApp or RDS servers. Six servers is a large enough number to make the data statistically relevant in most environments.
- Install Splunk
- Install uberAgent on six XenApp/RDS servers
- Confirm things are working
- Wait two weeks while data is collected
- Transfer the data to an analysis machine
- Write a report
The following sections explain each of these steps in detail.
Although installing Splunk is simple and straightforward, be sure to follow our instructions closely. When choosing a server for Splunk keep in mind that it needs enough hard disk capacity to store 14 x 500 MB x compression = around 1 GB. By default Splunk stores its data where you install it so the easiest way to have Splunk store data on a partition different than C: is to install Splunk where you want the data to be.
If you create a virtual machine for Splunk configure at least 2 vCPUs and 8 GB RAM – of course, more is always better. In this case it will make the searches run faster.
All in all it should not take longer than 30 minutes to install Splunk.
Following our instructions you should have uberAgent up and running in no time. Please note that if you use PVS or another imaging method you need to prepare Splunk’s Universal Forwarder for that. Details are in the instructions.
After installation uberAgent will display a splash screen during logon as an enticement to get a license. Contact us, we are happy to provide time-limited evaluation licenses.
Once everything is installed log on to Splunk and navigate to the uberAgent app using the menu in the upper right corner:
You will see an empty User Session Overview dashboard. Empty because no data has been collected yet, of course. Do not worry, it will be much more beautiful later, e.g. like this:
Log on with a test user to one of the monitored servers. Wait one minute and then refresh the dashboard. You should now see some data.
Use uberAgent’s menu to nativgate to the Machine Detail dashboard:
Make sure you get data from each of your servers. It should look similar to this:
There is not much to say about this except that you probably should not pick the holiday season for your data collection. You want two typical weeks.
Depending on your situation it may be feasible to analyze the data using the customer’s Splunk installation. You are more flexible, though, if you transfer it to a different analysis machine which can be off-premises. A typical consultant’s laptop would be suitable. You need to ask permission, of course.
To copy the index to another machine:
- Install Splunk on the analysis machine
- Stop the splunkd service on the source and target machines
- Copy C:\Program Files\Splunk\var\lib\splunk\uberagent to the analysis machine (same location)
- Start Splunk on analysis machine
- Tell Splunk about the new index by installing the uberAgent app on the analysis machine (uberAgent.tar.gz)
Use the dashboard Session Overview to determine per-session values. It shows you the maximum number of concurrent sessions:
Given that we monitored six servers the average maximum number of sessions per server is: 133 / 6 = 23
This value is, just like all the other values calculated here, rounded – to be on the safe side.
Use the dashboard Session 0 to find the CPU usage of all system services combined. In this example let us assume it is 4 %.
Use the dashboard Machine Detail to determine the maximum CPU usage, 20 % in this example:
Calculate the maximum CPU usage per session: (20 % – 4 %) / 23 sessions = 0.7 % / session
Calculate the server capacity by CPU only: (100 % – 4 %) / 0.7 % / session = 137 sessions
Use the dashboard Session 0 to find the RAM usage of all system services combined. In this example let us assume it is 1,500 MB.
Use the dashboard Machine Detail to determine the maximum RAM usage, 60 % in this example:
Calculate the maximum absolute RAM usage (assuming 24 GB installed): 24,576 MB * 60 % = 14,746 MB
Calculate the maximum absolute RAM used for user sessions: 14,746 MB – 1,500 MB = 13,246 MB
Calculate the maximum RAM usage per session: 13,246 MB / 23 sessions = 576 MB / session
Calculate the server capacity by RAM only: (24,576 MB – 1,500 MB) / 576 MB / session = 40 sessions
Use the dashboard Machine Disk IO to determine the maximum hard disk usage, 50 % in this example:
You may also want to take a look at IOPS:
Write ratio (how many of the IOPS are writes):
Latency (how long does it take for an IO to be processed):
Calculate the maximum disk usage per session: 50 % / 23 sessions = 2.2 % / session
Calculate the server capacity by disk only: 100 % / 2.2 % / session = 45 sessions
The network utilization of XenApp/RDS servers is typically so small that it can be neglected:
Looking at the CPU only, each server supports 137 sessions. Looking at RAM only that number drops to 40. For the disk it is 45. Obviously these servers have too much CPU capacity. They are limited by RAM and disk equally. It might make sense to increase the RAM a little bit. Increasing the hard disk performance in terms of IOPS is typically not easily possible.
I will leave this to you.
Go do your own capacity reports!