Diagnosing performance

Diagnosing performance

Diagnosing performance issues is always hard and complicated, this is nothing that should be taken lightly.

Before you begin, you should try to familiarize your self with all the components of WorkBook.

It is recommend that you:

  • Use the guide from the top to the bottom
  • Write down all your findings (In case you need to contact our support)

Diagnosing from the Client Machine

It is always recommend that you start on the machine where you notice the issue.

The issue may be related to that specific machine, or to WorkBook in general. It is therefore recommend that you try the following steps on two or more machines and document your results.

Disable addons

A lot of addons can interfere with regular network traffic, this includes but is not limited to:

  • Adblockers
  • Cookie trackers
  • Developer tools (Firebug, etc)

Access the following address

The following files on each installation are static, and allows you to test the performance between the client and the server.
If these files download slowly it is most likely a network issue, or disk performance on either client or server.

  • <Version 8 base address>/ClientBin/WorkBook.xap
  • <Version 9 base address>/images/images.html

If these files download slowly the first time, and fast the second time its because they are cached on the client.
Either stop the client from caching or add a cache breaker, by appending a random query string at the end of the address (?randomCacheBreaker22)

Ping the server

A typical issue is timeout. Timeout can either come from poor server performance or poor connection reliability / speed
In the previous step we looked at the network speed, we will now look at the reliability.

Open a command line / shell and write the following:

  • Windows: ping <server address> -t
  • OSX: ping <server address>

Check and see if these utilities report that they are unable to send/receive packages.
If so, it is most likely an unstable connection.

Speedtest

If your WorkBook is on a hosted system, in one of our international locations, try running the following speedtest as well:

Client Performance

WorkBook is a rather “heavy” web application, it uses a lot of resources for rendering and logic computation.

Make sure to check the utilization of the following resources:

  • CPU (When navigating in the application)
  • Memory usage

Build in browser diagnostics

From Version 9, most of the built in browser diagnostics tools can be useful if you know how to use them.

In most major browser you find a option to open “Developer Tools”, these tools often contain a “Network” or “Network Performance”
The “Network Performance” is useful for finding which call is timing out, if some of them are very slow.

If you want to provide our developers with this information, then we recommend exporting it as an HTTP Archive.

Web Server Diagnostics

This step can only be done on-premises, if a hosted solution is used you must have WorkBook check it for you.

Event Logs

The IIS, WAS and ASP.NET logs information to the Event Logs.
Some of this information can be used to diagnose some performance issues.

For the IIS & ASP.NET you should look in “Windows Logs \ Application” for timeouts and exceptions.
Timeout has the biggest impact on performance, for exceptions to have an impact on performance a lot of exceptions must be thrown.

For WAS you should look in “Windows Logs \ System”
The main thing to look for here is often recycling of the application pool serving your sites.

Server Performance

You should check the following resources and their utilization:

  • CPU – Most of the application in single threaded, so it’s important that you check if a single core is fully utilized.
  • Memory – You should always have 1 GB of memory to spare, and preferably more.
  • Disk Activity – Ensure that the disks are not at 100% use all the time, or everything has to wait.

SQL Server Diagnostics

This step can only be done on-premises, if a hosted solution is used you must have WorkBook check it for you.

Activity Monitor

The SQL Server has a built in Activity Monitor that useful for getting an idea of whats happening right now.

In the Activity Monitor you should check the following:

  • Processes
    • If any process is head of a blocking chain, and stays that way for longer then a couple of seconds
    • If there are many more processes then users online (%OnlineUsers%x4 > Processes)
  • Data File I/O
    • An healthy database has very low I/O utilization (Ignore the tempdb)

Performance Counters

The SQL Server has multiple performance counters, some of these are worth watching.

You can monitor performance counters using the build in “Performance Monitor

  • Database\Active Transactions – Most transactions should not stay active for long, this number should stay more or less constant.
  • Buffer Manager\Page Life Expectancy – This number should stay high and never drop during regular usage. Otherwise your server most likely needs more memory.
Was this article helpful? Useful Useless 0/4 found this article helpful.