In the previous post you have seen how to handle the perils of JavaScript and we also touched on the topic of clean and maintainable transactions. Today we will continue with a few more tips on how to make the transactions more maintainable and we will discuss common issues with playbacks.

 

Add some pauses

There are many variables which influence the performance of monitored web applications. Responses are sometimes quick and your page is displayed instantly, but if IT decides it’s a good time to backup the main servers then you might experience delays and variations in response times. There might be many other reasons like Internet connection problems, performance issues on the side of your browser or operating system, or simply the web application is still under development and it has not been optimized for performance. Java applets are a good example where you might need to watch the load time more carefully. Slow load times can not only cause variations in response times, but can even cause the transaction to fail.

 

Variations in response times and false alerts about failed transactions make it difficult to fine-tune your web application performance monitoring. Thresholds you have defined can be reached and false alarms can be triggered just because of this variance in the network.

 

If you have these kinds of problems, consider adding a few ‘waits’ to the transaction. If you see the response time of your action varies between 1-4 seconds, simply add a 5 second wait after your step to accommodate that variation. Wait times won’t count into the overall timing of the transaction, but will help to absorb the changes in the response times. Click on the Add Wait Time button (in yellow on the screenshot below) and define how long to wait (in blue).

 

adding_wait.png

 

Alternatively you can use an image match. Image match will wait up until the defined number of seconds (by default 30s) until the image is loaded. Waiting time is counted into the duration of a transaction; however, if the image match expires before the image is loaded, the whole transaction will fail. Click on Image Match button (in yellow), mark the area to match (in red) and define how long to wait (in blue).

 

image_match.png

 

Playback

 

Browser Versions

Web Performance Monitor is using the Internet Explorer browser to play back your transactions. One of the great features of WPM is the ability to use remote players and thus provide performance data from various locations (offices, branches, customer regions and so on). However each remote player might use a different version of Internet Explorer and this brings variations into your playbacks. Different versions of Internet Explorer could interpret a code differently and display the page with small variations that might result in different response times or failures in the transaction playback.

 

When you are recording a transaction double-check the version of the browser on the machine where you make the recording and the versions on all your remote players and make sure they are same. Even the small difference can make actions like 'Image match' fail.

 

IE8_9_difference.png

 

Optimize the load

A WPM recording is a copy of what a user does in Internet Explorer. This fact has certain requirements for memory and CPU. That is also a reason why you can’t have hundreds of transactions on one player. It is like having hundreds of users using the same computer (just recall how slow can be your browser when you have too many tabs open. If you assign too many transactions to one player it might affect response times and performance data and cause false alarms for failed transactions.

 

To optimize utilization of the players we provide you with load indicator for each player.

 

load_indicator.png

 

The value of the indicator can range from 0 to hundreds (%).  What does this value mean? Here is the simplified formula to calculate the load:

 

player_load = number_of_running_playbacks / total_number_of_playback_workers*100 + transactions_waiting_for_playback

 

The transactions_waiting_for_playback value is based on the sum of wait times of the transactions on the player before they are played back. The longer the transactions wait for playback on the player the higher this value gets.

 

Basically it says how well you utilize your player to playback transactions. Most of the time you want to have it around 100% (or even slight above). There might be ups and downs, and you might experience short spikes and therefore what you need to look at is the status in the long-term. If the load is consistently below 100% there is still capacity to handle more transactions. If the load is consistently above 100% it means your player is too busy and it might have an impact on performance data.

 

player_load_history.png

 

What are the options?

 

  1. Simplify transactions
  2. Reduce the frequency of playbacks
  3. Move transactions to another player
  4. Add resources to the player

 

Simplify the transactions as we described in the previous post. Make sure each transaction is simple and minimalistic and contains only actions that are needed to verify application functionality or for which you want to collect performance data.

 

Reduce the frequency of playbacks so that it still gives you information you need, but balances the number of transactions on a given player. Simply edit transaction in the UI and make it run once per hour instead of every 5 minutes.

 

transaction_playback_frequency.png

 

Consider moving the transaction to another player and check the impact on the load indicator of the original player. You might want to group similar transaction to one player or dedicate a player for the transactions which exercise some of the more complex business logic of your application and consume more resources and time.

 

Add resources to the player. More RAM and CPU can help, but not always. Also, there are internal limitations of Internet Explorer. WPM therefore limits the number of workers on external players to 7 (workers on main poller are limited to 2). Generally horizontal scaling works better than vertical scaling.

 

In this post we have learned how adding waits to the transaction can help to absorb variations in response times We also learned that different versions of browsers interpret the page differently, sometimes causing false alerts, and lastly we discussed how to optimize the load of your players.

 

In the next post we will look at how to use and troubleshoot transactions monitoring desktop applications using Citrix XenApp.

 

Get the most of your Web Performance Monitor