[THIN] Re: Performance Metrics

  • From: "Bernd Harzog" <Bernd.Harzog@xxxxxxxxxxx>
  • To: <thin@xxxxxxxxxxxxx>
  • Date: Tue, 6 Apr 2004 11:27:09 -0400

Michael,

This is not only not a dumb question, but also one of the hardest to =
answer. Since we sell a product that improves capacity, and performance =
(if you are at or near capacity), we end up having this conversation =
with our prospects and customers quite frequently. Here is our opinion:

Perfmon measures the degree to which resources on the computer are =
utilized. The simplest example of this is CPU utilization. In our =
opinion you cannot infer performance from utilization counters. What I =
mean by this is that you can probably know that performance is "bad" if =
all of the CPU's on a server are pegged at 100% for a long time, but =
there is no way to know that response time to the end user will be =
better with CPU at 40% as opposed to 60%

Furthermore, Perfmon counters do not tell you the whole story. The leave =
out crucial pieces of information. Let me give you a simple example. =
Bring up Task Manager. Add CPU Time (the one that shows accumulated CPU =
usage since the process was started), and Page Faults. Sort by CPU Time =
so that processes that have used zero CPU time are at the top. Notice =
that on any machine that you do this, that you will have several =
processes that have used zero CPU time, but which have generated page =
faults. How is it possible for a process to have generated a page fault =
(which means that the CPU used time to recall a page from the page =
file), but that it did this without using any CPU time? Answer, the CPU =
utilization counters in Perfmon are dangerously misleading. They do not =
include the time that the OS spends performing many Kernel operations, =
and they miss all operations that occur in between the 10 millisecond =
interrupt timer of the OS. So, you can have a process that is using no =
CPU while it is waiting for the kernel to do something for it, and have =
the whole system report no CPU usage while the user is seeing terrible =
response times.

The only way to really measure performance is real end user experience. =
There are only two ways to really do this.

One, you can use a tool like Mercury Interactive Topaz to write a script =
that constantly runs through a set of actions in the applications that =
your users use (essentially creating a synthetic user on your system) =
and which will report back how long each transaction takes. This will =
tell you how long this synthetic user takes to do things in the context =
of how busy the server is. If you decide to do this for ever important =
application on your server and then have a synthetic user for ever =
server, be prepared to spend an eternity writing and maintaining the =
scripts and a fortune on the licenses required.

Two, you can try to use an appliance that can sit on your network and =
watch packets and tell you how much of the round trip time from a user =
action to the response is the WAN, the LAN, and the server. This is the =
new and very cool way to do this. If you are running a pure IP network =
(no ICA) there is a vendor, Netqos (www.netquos), that makes an =
appliance that you plug into a mirror port on your switch. It can tell =
you for all of the servers on that switch what the mix of delay is =
across the WAN, the LAN and the server itself. The good news here is =
that one box can handle all of the servers attached to one switch. The =
bad news is that the box does not understand ICA.

Now, when you try to find an appliance that can do this for ICA, the =
task gets difficult. Packeteer makes a version of its box called a =
PacketSeeker. If you put two LAN ports on the PacketSeeker, then you can =
put it inline in between two servers and their switch. Packeteer =
understands (can crack into) the ICA protocol, so it can tell you on a =
per published application basis what the response time is and how the =
delay is distributed across the network and the server. We do this at =
trade shows to demonstrate how TScale reduces server delay (I am going =
to email you some screen shots of list, since I do not think I can embed =
the images list emails). The good news here is that a Packetseeker can =
tell you exactly what performance is on a Citrix server and how it is =
distributed. The bad news is that you need one Packeteer box for every =
two servers if you want to deploy this across your whole farm.

As for you question about what is good and bad performance, the only =
serious answer I can give you is good performance is response times that =
are sufficiently good so that your users do not constantly complain or =
stage a revolt to get their fat clients back.=20

I hope this helps.

Best Regards,

Bernd Harzog
CEO
RTO Software, Inc.
bernd.harzog@xxxxxxxxxxx
678-455-5506 x701
www.rtosoft.com

 -----Original Message-----
From:   Woodward, Michael [mailto:Michael.Woodward@xxxxxxxxxxxxxx]=20
Sent:   Tuesday, April 06, 2004 10:39 AM
To:     'thin@xxxxxxxxxxxxx'
Subject:        [THIN] Performance Metrics

I asked this question before but I am going to ask it in a different way
this time. =20
What is the best way to measure performance on a Citrix server?  I have
complaints from users stating their session is slow, but I have to find =
a
way to answer the following questions:

1. 'How slow is slow?'=20
2. 'Is it due to the load on the servers?'
3. 'How do we know it is not the network?'

I have been directed to the Citrix Server test kit but this looks like =
it is
only testing performance of hardware performing specific scripts by a
certain number of users.

What about measuring what is occurring right now on my servers?  And =
maybe
this is a dumb question but if performance monitor is the answer what
counters should I be looking at for this information?  Is performance
monitor the best tool at measuring these things?=20

-----

C. Michael Woodward
Mid-Tier Support

Sun Chemical
Cincinnati, Ohio 45232
* 513.681.5950 x 576
* Michael.Woodward@xxxxxxxxxxxxxx





********************************************************
This Week's Sponsor - RTO Software / TScale
What's keeping you from getting more from your terminal servers? Did you
know, in most cases, CPU Utilization IS NOT the single biggest
constraint to scaling up?! Get this free white paper to understand the
real constraints & how to overcome them. SAVE MONEY by scaling-up rather
than buying more servers.
http://www.rtosoft.com/Enter.asp?ID=3D147
**********************************************************
Useful Thin Client Computing Links are available at:
http://thin.net/links.cfm
***********************************************************
For Archives, to Unsubscribe, Subscribe or=20
set Digest or Vacation mode use the below link:
http://thin.net/citrixlist.cfm


********************************************************
This Week's Sponsor - RTO Software / TScale
What's keeping you from getting more from your terminal servers? Did you
know, in most cases, CPU Utilization IS NOT the single biggest
constraint to scaling up?! Get this free white paper to understand the
real constraints & how to overcome them. SAVE MONEY by scaling-up rather
than buying more servers.
http://www.rtosoft.com/Enter.asp?ID=147
**********************************************************
Useful Thin Client Computing Links are available at:
http://thin.net/links.cfm
***********************************************************
For Archives, to Unsubscribe, Subscribe or 
set Digest or Vacation mode use the below link:
http://thin.net/citrixlist.cfm

Other related posts: