PerformanceGuard monitors how well your organization's computers, networks and servers work. PerformanceGuard specializes in how IT performance affects users' ability to work efficiently.
Your organization must have installed PerformanceGuard before you can use this information. Ask your PerformanceGuard administrator if you're in doubt.
Open a browser and connect to PerformanceGuard at the address you have received from your PerformanceGuard administrator. Then log in to the PerformanceGuard web interface with the user name and password that you have received from your PerformanceGuard administrator.
| Tip |
|---|
|
| In some organizations you don't need to log in to PerformanceGuard because you automatically get access based on your Windows login. |
The web interface contains dashboards that provide performance overviews at a glance. When you want to analyze performance, the web interface lets you delve into graphs and tables with very detailed information. When you want to share performance information with your colleagues, the web interface lets you generate reports in standard and custom formats.
Your use role determines what kinds of performance information you can view:
This access is typically relevant for Service Desk personnel so that they can diagnose performance problems if a user complains. IT managers and analysts typically also use this detailed information in their strategic planning of the organization's IT infrastructure.
Ask your PerformanceGuard administrator if you're in doubt about what kinds of information you have access to.
PerformanceGuard can help you with many typical performance information needs. Note that this list is by no means exhaustive; you have many other options for finding information in PerformanceGuard.
This is what to do when you want to know ...
You get a call from a user. Her computer is slow — can you fix it, please? The first thing that you want to determine is whether the computer really is slow. If yes, the next thing you want to find out is what slows the computer down.
The Computer Overview dashboard (Dashboards > Computer Overview) has a Computer Event Timeline Widget that makes it easy to determine if a selected computer has had performance problems. If it has, the widget makes it easy to see exactly which problems the computer has had, and exactly when they happened.
The widget looks at events that have happened on the selected computer, and displays them as bubble markers on a timeline. Remember what an event is? It's a threshold violation, for example a response time that isn't acceptable. You can zoom in on relevant events and click the bubbles to view details.
When a user calls you about a problem, you often need to determine the scale of the problem: Whether the user's computer is the only one that has the problem, or whether other computers have the same problem.
The Computer Overview dashboard (Dashboards > Computer Overview) tells you just that. When you look up a computer on that dashboard, its Computer and Neighborhood Status Widget compares the performance of the computer with the performance of other computers nearby.
Click the thumbnail to view an example where the problem clearly only affects a single computer.
| Expand |
|---|
| title | ... Who Uses Resources |
|---|
|
PerformanceGuard helps you identify resource-consuming users and processes in seconds. | Expand |
|---|
| title | Who Uses Most CPU Power and RAM? |
|---|
| PerformanceGuard helps you quickly identify your "resource thieves:" processes and users who consume excessive amounts of resources like CPU power and RAM. - The quick overview: The Processes and Users graph (ANALYZE > Graphs > Combined Bar Charts > Processes & Users) provides the overview in an easy-to-view bar chart format, no matter whether you are looking for resource-consuming users or processes.
 - The details: The Process Resources hotspot (ANALYZE > Overview > Hotspots > Process Resources) provides detailed data about resource-consuming processes, and you can drill down to view which computers and user accounts ran a given process.
|
|
| Expand |
|---|
| title | ... Who Generates Most IP Traffic |
|---|
|
Do you suspect that something is eating up your bandwidth? Or do you simply want to know if a particular application or location generates a lot of traffic? Would you like to know when traffic occurs? PerformanceGuard provides the answers: | Expand |
|---|
| title | Which Applications Generate Most IP Traffic? |
|---|
| In PerformanceGuard an application consists of a server/port combination, for example server.organization.org on TCP port 80 (HTTP). The IP Traffic by Application time view graph (ANALYZE > Graphs > Time View > IP Traffic by application) shows which applications generated IP traffic, and when they did it. You can view this data for combinations of all servers and ports, groups of servers and ports, and individual servers and ports. | Tip |
|---|
| | The graph is also available in a trend view variant. It contains the same type of information, but the trend variant is more suitable if you want to view data from more than the last few days. |
| Tip |
|---|
| | If you simply want to find out if a particular program (such as Skype) generates a lot of traffic, it is often easier to look for the process (such as skype.exe) instead. See Which Processes Generate Most IP Traffic? in the following. |
|
| Expand |
|---|
| title | Which Processes Generate Most IP Traffic? |
|---|
| - The quick overview: The Load Overview (ANALYZE > Overview > IP Traffic > Load Overview) is a pie chart that very quickly lets you find the processes that are responsible for the largest amounts of IP traffic. When you generate the pie chart, try to select Type = Processes and Data type = Load (Sent + Received Bytes).
 - The details: The Process Traffic hotspot (ANALYZE > Overview > HotSpots > Process Traffic) provides detailed data about traffic-generating processes, and you can drill down to view details about which servers the process communicated with as well as details about which computers and user accounts ran a given process.
- The timing aspect: The IP Traffic by Process graph (ANALYZE > Graphs > Time View > IP Traffic by process) is ideal when you want to check if certain processes generate traffic at specific times. You can view this for all servers, for groups of servers, or for individual servers.
|
| Expand |
|---|
| title | Which Locations Generate Most IP Traffic? |
|---|
| The IP Traffic by Location time view graph (ANALYZE > Graphs > Time View > IP Traffic by location) shows which locations that generated IP traffic, and when they did it. You can view this for individual servers and ports that the locations have communicated with. | Tip |
|---|
| | The graph is also available in a trend view variant. It contains the same type of information, but the trend variant is more suitable if you want to view data from more than the last few days. |
| Tip |
|---|
| | If you want to compare locations, select all the locations you require in the graph's Agents list. Don't simply select All agents because that won't let you view the traffic generated by individual locations. |
|
|
| Expand |
|---|
| title | ... If Some Servers Are Overloaded |
|---|
|
Look at server response times: If many of a server's responses are slow, it is typically because the server's hardware is not able to cope with the amount of work that the server has to do. | Expand |
|---|
| title | Do Servers Respond Quickly? |
|---|
| The Response Time Histogram displays response times for selected servers. To view the histogram, select ANALYZE > Graphs > Statistics > Histogram. The histogram consists of 10 individual bars. Each bar represents the percentage of replies within a given milliseconds interval. This way you can very quickly find out if a particular server is potentially overloaded — like the blue one  in the example image. 
| Tip |
|---|
| | In the example, we use the histogram to spot a potentially overloaded server. However, the main benefit of the histogram is that it helps you verify if a high average response time is caused by a major or a minor ratio of the total requests. This in turn can help you determine whether a high average response time is really a problem. |
| Info |
|---|
| | Expand |
|---|
| title | How can a high average response time not be a problem? |
|---|
| | If a high average response time is caused by a few responses in the 2000-500000 milliseconds interval while the majority of responses are in the 0-10 milliseconds interval, the high average may not be a problem. This of course also depends on your type of organization, which types of applications and servers you run, how business-critical your applications are, etc. |
|
|
| Expand |
|---|
| title | Can Servers Handle Pressure? |
|---|
| The Response Times Versus Load graph (ANALYZE > Graphs > Statistics > Response Time Versus Load) can help you uncover otherwise hidden scaling problems. If response times increase to a non-acceptable level when the number of requests per second increases, it's very likely the result of an overloaded server getting more requests than it can handle.
In the example (click thumbnail to view image in full size), the gray  server responds quickly no matter how many requests it gets. However, the response times (horizontal axis) of the purple  server dramatically increase when the server gets many requests (vertical axis)—a typical sign of an overloaded server that could benefit from a hardware upgrade in order to perform better at busy times. |
|
| Expand |
|---|
| title | ... If Web-Based Applications Work Efficiently |
|---|
|
The PerformanceGuard transaction filters feature is highly useful for monitoring web-based applications. | Info |
|---|
| | Expand |
|---|
| title | What's a transaction filter? |
|---|
| | It's a definition of things to look out for in a web request—for example images so that you can measure how long it takes before all images on a web page are available for the user to view in his or her browser. Transaction filters are very flexible: PerformanceGuard administrators can define more or less any element of a web request as a thing to look out for. |
|
| Expand |
|---|
| title | How Long Does It Take to Get Responses? |
|---|
| The Web Activities (Time View) graph (ANALYZE > Graphs > Time View > Transactions) shows you how long it takes for computers on all or individual parts of your organization to get responses when they make web requests. This can help you verify how efficiently users are able to work with web-based applications. | Tip |
|---|
| | The graph is also available in a trend view variant. It contains the same type of information, but the trend variant is more suitable if you want to view data from more than the last few days. |
|
| Expand |
|---|
| title | Does a Specific Element Cause Trouble? |
|---|
| The Compare Web Activities graph (ANALYZE > Graphs > Combined Bar Charts > Compare Transactions) lets you compare the various transactions under a single transaction filter. That way you can, for example, detect if a specific element of a web request takes longer to access than other elements. In the example (click thumbnail to view image in full size), it is evident that one of the elements in the web request takes much longer to access than the other elements.  Image Modified
|
|
| Expand |
|---|
| title | ... If Network Latency Causes Trouble |
|---|
|
The Traceroute Graph (ANALYZE > Overview > Trace Route > Trace Route Graph) helps you quickly detect any network latency. A traceroute detects and captures the path that a network packet will travel from a given starting point (a computer that has the PerformanceGuard agent installed) to a specific destination. While PerformanceGuard detects the route, it will also record the network latency between different routers along the route until reaching the final destination. The results are displayed as an easy-to-understand network map.  Image Modified
The traceroute graph requires that your organization has set up traceroutes. Read more about traceroutes and other similar types measurements in Monitor Availability, Latency and Response Times with Application Ping. |
| Expand |
|---|
| title | ... If Performance Is Good or Bad |
|---|
|
The answer to this question depends almost entirely on the type of work that you do in your organization. However, there are some rules of thumb, that it makes good sense to follow in almost any type of organization: See When Is Performance Good or Bad? |
| Expand |
|---|
| title | Frequently Asked Questions About Availability |
|---|
|
Many PerformanceGuard graphs are able to show the availability of servers, etc., but what is availability?
| Info |
|---|
| | Expand |
|---|
| title | When is something considered to be available? |
|---|
| To answer this we need to look at response times: If response times are so long that use of a service, website, transaction or similar becomes impossible, PerformanceGuard considers the service, etc. to be unavailable. By default, PerformanceGuard loses its patience with a service, etc. if it hasn't responded within 500,000 milliseconds (that's a little more than eight minutes). Everything that's not unavailable, is considered by PerformanceGuard to be available. So, if you see that a service has been 100% available during the last week, it means that it has not exceeded the acceptable response time limit during the last week.
| Expand |
|---|
| title | Do you measure availability of application pings (HTTP requests, ICMP ping and/or traceroutes)? |
|---|
| | For application pings, PerformanceGuard looks not only at acceptable response times, but also at whether a response is expected or not: If the response is unexpected, for example if the response has a response code of 404 Not Found, PerformanceGuard considers the service to be unavailable, even if the response was received within acceptable time. |
|
|
| Info |
|---|
| | Expand |
|---|
| title | How does PerformanceGuard calculate the availability %? |
|---|
| | PerformanceGuard looks at the ratio between failed requests and all requests in percent. In other words: (all requests − failed requests) / all requests × 100 |
|
| Info |
|---|
| | Expand |
|---|
| title | I just set up a new server. Nobody has used it yet. How can it be 100% available? |
|---|
| | Bear in mind that PerformanceGuard looks at your new server based on how the PerformanceGuard agents experience it: If none of the computers with PerformanceGuard agents have used the new server, there have not been any unacceptably long response times, and the server has thus not been unavailable. Everything that's not unavailable, is considered by PerformanceGuard to be available, and that explains the 100% availability, even though nobody has yet used your new server. |
|
|
When you're ready for more, simply try out the many different graphs, reports, dashboards, etc. Each of them have matching help, so just click the help icon if you need to know more.