Collecting data for client performance issues

Merative ™ Social Program Management is now Cúram ™ by Merative™

Collecting data for Merative ™ Social Program Management client performance issues

Question & Answer

Question

What information should be collected for client performance issues, including blank/white screens as well as hanging application buttons and menus reported in Merative Social Program Management?

Answer

• Browser compatibility mode settings
  For Internet Explorer, confirm the Browser Mode and Document Mode on the user's machine encountering the issue. This is done by pressing F12 in the browser window and taking note of the browser and document modes listed.\
• Browser Plugins
  All plug-ins must be disabled. This includes disabling antivirus plug-ins. This can be done, for example, in Internet Explorer by selecting Tools -> Manage Add-ons to view the list of installed add-ons.\
• Machine Specifications
  Include information on the Operating System and specification of the machine.
  - Operating system type and version
  - Processor
  - Installed Memory (RAM)
  
  List of any Internet Explorer workarounds installed.
• Usage scenarios
  If the issue is reproducible, please provide step-by-step instructions. Any usage scenarios that can be provided will help narrow down the cause of the issue.

Please describe how the UI and the browser are used by your users.

More specifically, do they do the following actions weekly, multiple times weekly, daily or multiple times daily?

- How often do they close tabs?

- How often do they use the browser refresh button on Merative Social Program Management?

- How often do they logout?

- How often do they close the browser?

• Server response times- Is the user local or remote?
  - Are there any potential performance issues with the server?
  - Are there any potential network issues with response times?
  - What network bandwidth is the user encountering at the time?HTML Source for blank page To get the HTML source in Internet Explorer, right click and choose the View Source option. In Chrome, the View Frame Source option should be used.
• UI memory leak data If it is found that the memory footprint of the browser accessing the application is increasing to un-sustainable levels, the issues could be due to memory issues with the browser itself or indeed memory issues with the user interface portions of the application. To help diagnose these issues, the following questions/steps should be followed:** **
  • If this issue is observed when traversing custom functionality, can it also be reproduced using a clean OOTB install?
  • Always begin testing by clearing the browser cache (and as mentioned above, disabling add-ons). For example in Microsoft's Internet Explorer 11, select CTRL + SHIFT + DEL. Uncheck "Preserve Favourites website data", check everything else and click delete. Then select F12 to open developer tools, select Network and using the hover tooltips find the button for "Clear browser cache" and select it and confirm.
  • After clearing the cache, close down the browser and check that all it's processes end. If they did not, force them closed before re-launching it.
  • Analyzing a memory issue should start by reproducing it and gathering memory numbers from the OS and from the browser's developer tools. If the browser developer tools show little growth and the OS shows substantial growth, the issue is liable to be in a part of the browser that the developer tools cannot analyze. If the browser developer tools show growth proportionate to those from the OS, then the browser developer tools should prove useful. Typically some browsers deal poorly with perfectly legitimate, best-practice, user interface source on the page. This can mean that they incorrectly hold objects in memory that the UI source has correctly cleaned up and de-referenced for garbage collection.
  • Define the simplest out of the box (OOTB) scenario possible, in meticulous detail regarding every click, with memory statistics as follows:
    a) after logon
    b) after arriving at the point where every iteration of the scenario begins (e.g. the Person Search results page)
    c) at the end of the iteration
    d) define which tabs are closed between iterations
    e) after the final iteration close all tabs and record another memory reading
    f) logout and take a final memory reading
  • If there is a severe memory issue, run a number of iterations until the browser becomes unusable or crashes. Otherwise run enough iterations to highlight the issue.
  • The statistic that takes highest priority is from the browser's process listed within the operating system's own process monitor. This is the Task Manager on the Windows platform or Activity Monitor on a Macintosh. Sometimes browsers will have multiple processes running despite using only a single tab on a single window. Record the memory readings of each process. Their process identifiers should be unique if you need to track them.
  • To determine if the issue is caused within the UI source, the Javascript Heap (i.e. long lived JavaScript objects, the difference between objects created and deleted) will require further investigation. Chrome and IE both have developer tools to aid with this process but if a spike on each shows that the issue is reproducible in Chrome, then we recommend using it's developer tools. They are more stable and less likely to cause the browser to lock or crash or vastly increase it's memory consumption.

IE:

Follow Microsoft's own instructions and take "snapshots" where above we mentioned taking memory readings. Typically you can only take 5-10 before IE becomes unusable.

See Diagnosing memory problems in your webpages for further details on how to achieve this.

Chrome:-

As with IE , take snapshots rather than (or as well as) memory readings.

See How to Record Heap Snapshots for further details on how to achieve this.

• Once you have a few snapshots, compare the objects in memory. A brief example of how to accomplish this is detailed below:
  
  Snapshot X includes objects A,B,C,D
  caseworker opens a tab
  Snapshot Y includes objects A,C,D,F,G
  
  Therefore
  - Object B must have been a delayed garbage collected object irrelevant to what was open @ X
  - Objects F,G must be new objects required to open the new tab
  
  caseworker closes the same tab
  Snapshot Z includes objects C,D,F
  
  Therefore
  - Obect A must have been a delayed garbage collected object irrelevant to what was open @ X
  - Object G must have been garbage collected correctly
  - Object F may eventually get garbage collected but until we see that happen it's the only thing worth investigating further as it's the only potential leak
• Browser JavaScript Logging and Network Traffic: Global Enabling of Client and Browser Tier Debugging In the CDEJResources.properties file located in the curam/omega3/i18n directory, set
  
  TraceOn=true
  JavaScriptTraceOn=true
  
  At development time, add this file to your webclient project in a custom component, before building the application.
  
  At runtime, a copy of the file can be found in the properties.jar located in the WEB-INF\lib directory of the ClientModule.war file (within the Cúram EAR file). For example,
  
  1. Locate the client WEB-INF\lib directory installed in WebSphere:
  <WAS_HOME>profiles\<profile>\installedApps\<node>\Curam.ear\ClientModule.war\WEB-INF\lib
  
  2. Extract a copy of CDEJResource.properties from the properties.jar located in this directory. The file should have the package curam\omega3\i18n.
  
  3. Place this copy in the <WAS_HOME>profiles\<profile>\installedApps\<node>\Curam.ear\ClientModule.war\WEB-INF\classes\curam\omega3\i18n directory, modifying it to set the above properties.
  
  4. Restart the server
  
  To do this, open a command prompt and from the '%CURAMSDEJ%\bin' directory run the commands below to stop and start the server.
  
  ant -f build.xml stopserver -Dserver.name=%server_name%
  ant -f build.xml startserver -Dserver.name=%server_name%
  
  5. When the issue occurs again, zip up the logs directory and provide this to Merative Support.
• Browser JavaScript Logging and Network Traffic: Local Enabling of Browser JavaScript Tracing Enable the browser JavaScript tracing locally for a user using a web debugging proxy tool. There are a number of tools that can be used including the Fiddler2 Web Debugger tool.
  
  If using Fiddler, then the following approach can be used to modify the DEBUG variable and capture the output:
  
  1. Unencrypt the HTTPS content in Fiddler. This can be done using the Tools -> Fiddler Options menu. Select the HTTPS tab and tick the decrypt HTTPS traffic.
  
  2. Select Rules -> Customize Rules... in the Fiddler menu
  
  3. In the file that opens find the onBeforeResponse function and add the following line:
  
  static function OnBeforeResponse(oSession: Session) {
  ......
  oSession.utilReplaceInResponse("var DEBUG=false;", "var DEBUG=true;");
  }
  
  4. Save the file. Any subsequent application access, with Fiddler running, will result in debug output.
  
  5. Using Internet Explorer Developer Tools accessed by pressing F12, display the Script Console view.
  
  6. Reproduce the issue.
  
  7. Copy and save the resulting debug output and send it to Merative support. Also include the traffic captured by Fiddler itself. This will allow Merative support to review network traffic and determine if connections are being lost.Note: Both debugging options, global and local, have performance implications so may not be possible to set in a production system.