EditAttachPrintable
r40 - 2013-05-13 - 18:14:44 - Main.sbeardYou are here: TWiki >  Deployment Web > DeploymentTroubleshooting > PerformanceTroubleshooting > BrowserPerformance

new.png Why is browser performance slow?

Authors: StephanieBagot
Build basis: CLM 4.x

This situation will help to determine why there is performance degradation within the web UI of IBM CLM applications.

Why does performance vary between browsers?

The performance of the browser's JavaScript engine has a direct impact on the perceived end user performance in web applications. The entire RTC Web UI is run in JavaScript (except some Flash reports), so the browser must load the dojo toolkit plus thousands of JavaScript classes. The JavaScript engine must parse and execute this information. Most browser vendors/versions have different JavaScript engines, each with different abilities to interpret and run the JavaScript, thus resulting in varying browser performance when loading the CLM applications. Therefore, excluding network latency and relatively short server response times, the performance of the CLM Web UI is directly proportional to the browser JavaScript engine speed.

It is important to note that there are plenty of articles available online which provide a browser comparison such as this one:
(NOTE: this link will take you to an external page) The Big Browser Benchmark Test.

Browser performance with CLM applications

The CLM Web UI has been optimized to improve performance in the code, by compressing and pre-processing the JavaScript to be optimized, but the Web UI Performance is still restricted based on the JavaScript engine capabilities.

Based on our experience, the performance of Mozilla Firefox or Google Chrome when running CLM applications can be significantly better than the performance of Microsoft Internet Explorer.

Some performance testing has been done against 3.x and 4.x and can be viewed under WAN Performance Testing. Some additional example measurements from our tests with CLM 4.0.1 are provided below. These tests were gathered using a combination of HTTPWatch (Firefox and Internet Explorer) and Speed Tracer (Chrome).


NOTE: The measurements provided should not be used as a baseline for browser performance in your environment. Your results may vary based on your environment: hardware, operating system, other running software, network, application server, database, authentication mechanism you use, etc. All measurements are in seconds.
Below is an average sample of loading times gathered between different browsers using a small set of functionality within Rational Team Concert. In order to validate this information in your environment, see the section below to determine how to run the comparative tests in your environment.

Scenario IE 8 FireFox 19 Chrome 26
Login without Project Area specified 3.93 3.70 3.60
Loading Small work item 9.27 5.30 4.54

Possible causes

There are generally two causes for slow browser performance:

1. User browser related issue
Performance from the web UI can be due to the browser JavaScript engine as discussed above.

2. Server Performance Issue
When overall browser performance is:

  • reported by all users; or
  • happens consistently at a certain time,
The slow browser performance may be caused by a server related issue such as network latency, database response time etc. This type of performance degradation will also be viewed in a rich client such as Eclipse. For this type of performance issue, navigate to How to Start a Troubleshooting Assessment to identify possible causes to further investigate. Various Performance Situations will be discussed on the Performance Troubleshooting page.

Recommended analysis steps

If you have experienced browser performance issues, navigate to Browser Performance to determine if the issue is related to the server/client configuration, or the actual browser itself.

Questions to identify the problem

  1. What URLs are being accessed? (ie. Are you going through a proxy, or right to the CLM Server)
  2. Are the browsers being run on the same LAN as the CLM Server? If not, keep in mind that the location of your user may cause some latency
  3. When does the performance degradation occur? ie. At peak hours, or when there is light user load

Analysis Steps

To investigate and analyze the performance degradation from within a browser, take the following steps:

  • Ensure that the browser cache is clean before running any browser tests for performance

  • Open up your process monitor and see how much memory or CPU usage your browser is taking.
    On the machine running the client browser, take a look at the memory utilization to determine if your browser is running as 'lean' as possible. Closing down tabs or the entire browser itself and restarting it may release some of the consumed memory if it is too high.

  • Deploy the Performance Health Check Dashboard Widget
    The Performance Health Check Dashboard Widget runs a number of tests to measure the performance of various systems in a CLM deployment including the client, application server and database server. If the widget displays reasonable response times for each of the tests (green), then the latency and throughput of your connection with the server is within reasonable times and is indicative of a healthy server. Looking at the two possible causes above; browser or server; green response times rule out server as a root cause for performance degradation, leaving the browser a possible culprit for the slow loading times.
    Alternatively, if the tests display red or slow response times, this shows that the connection with the server is not strong, leading to overall server performance (and not the specific browser) as root cause. If this is the case, navigate back to the Performance Troubleshooting main page to begin investigation into other possible causes for the slow performance.

  • Execute a comparative browser test
    In analyzing browser performance issues, it is important to determine if the product is causing the performance degradation, or the browser itself based on the limitations of the JavaScript engine as noted above. Running a comparative browser test will help to identify if Browser A is causing the problem, since the same function is displaying better performance in Browser B.
    HTTPWatch is a useful tool to inspect and monitor CSS, HTML, JavaScript and Internet requests in any web page and can help when investigating browser related performance issues. To learn how to use HTTPWatch in your analysis, navigate to How to Use HTTPWatch.
    Another useful tool is the [[http://www.webkit.org/perf/sunspider/sunspider.html][SunSpider JavaScript Benchmark] webkit which will compare the overall browser performance related to the JavaScript engine for the core JavaScript language only (not touching on DOM or browser APIs).
    Using the tools mentioned above, or others such as Firebug, or SpeedTracer, will trace the actual calls being made when loading a page within CLM. This information can be compared for varying performance across browsers (various browser add-ons may be needed for different vendors). See How to Use HTTPWatch for more instructions on using the tool.

Possible solutions

If the browser performance degradation is identified to be a browser problem, then:
Test the performance using a new browser (same vendor with different version or different vendor all together) to determine if the behaviour is the same.
  • For example, if using Internet Explorer, try testing in Firefox or Chrome, as long as the browser is a supported version. If you are unable to test using a different browser, try to test using a different version of the browser, such as IE 8 or 9. In our experience, Firefox and Chrome have increased performance over Internet Explorer.
  • If using a different browser did not result in increased performance, navigate back to the Performance Troubleshooting main page to begin investigation into other possible causes for the slow performance and perhaps look into tuning the overall server for better performance.


If the browser performance degradation was actually identified to be a server issue, then navigate to Performance Troubleshooting for additional topics on troubleshooting and tuning.

Tips to making Internet browsers run faster

  • Keep your browser up-to-date and patched
  • Make sure any plug-ins or extensions are up-to-date and patched
  • Remove any plug-ins or extensions you do not use
  • Think twice before customizing your browser
  • Run as lean as possible (ie. no customizations, don't open multiple tabs)
  • Ensure you keep the cache for any CLM application information as it will speed up the loading time of the web UI
  • Cookies will maintain your authentication, but can be deleted after your user session to keep your browser lean. Keep in mind that removing the cookies will also remove the saved username from the login splash screen (if you have it selected).

Related topics:

External links:

Additional contributors: None

Questions and comments:

Warning: Can't find topic Deployment.BrowserPerformanceComments

Edit | Attach | Printable | Raw View | Backlinks: Web, All Webs | History: r44 | r42 < r41 < r40 < r39 | More topic actions...
 
This site is powered by the TWiki collaboration platformCopyright © by IBM and non-IBM contributing authors. All material on this collaboration platform is the property of the contributing authors.
Contributions are governed by our Terms of Use. Please read the following disclaimer.