Browser-based applications can run more slowly or crash if memory usage becomes too high. If your browser approaches 1 GB of memory usage, you might experience issues.
Slow performance or browser crashes are often caused by the following conditions:
- Memory leaks: After processing and resolving a work item, the browser memory footprint should return to a number similar to where the memory footprint was before the work item was opened.
The following scenarios describe the steps for determining whether your application has a memory leak. You can reuse these diagnosis patterns on any application.
Example 1: Case Manager Portal
This scenario uses a simple work item in the Case Manager portal. Use a similar scenario to find memory leaks in any application or portal. When testing for a memory leak, run the test in your standard portal with a common use case that mimics a real-world user scenario.
- Log in to the portal as an end user and launch the Task Manager.
- Record the browser memory in Task Manager.
- After the case has been completed, return to your portal's home screen and observe the memory usage in Task Manager. Shortly after you close the case, the memory should be cleaned up and go down to a number close to the memory usage that you recorded in step 3.
- Repeat steps 3 through 5 above for as many cases as you expect a user to complete over the course of the work day. Document the before and after reading for each case. If the browser memory starts to get close to 1 GB or if the browser crashes or becomes sluggish before you can process a days' worth of work, you have a memory leak that must be addressed.
Repeat this test for each of the browsers that you support.
Note that if other web pages or web-based applications are open in other browser sessions or tabs, the memory usage of those applications or web pages appears as part of the total browser memory usage in Task Manager.
Example 2: Customer Service Application
Testing the Customer Service Application uses the same principles as the Case Manager portal, although it is built differently from the Case Manager portal. The use of Customer Service varies from contact center to contact center. Test for memory leaks by using typical usage patterns in your contact center. In some contact centers, a customer service representative (CSR) services only one customer at a time – a single interaction with one or more service items. In other contact centers (typically, those that service customers through the chat channel), the CSR might service multiple customers at the same time – multiple interactions with one or more service items per interaction. Every interaction and every service item is a work object, so the consequences of a memory leak amplify very quickly.
As in the Case Worker portal, run through the flow once to prime the system. Do not log off after priming the system. Then run your test, recording the memory usage after each step of the test. Use the same methods of recording memory as in the Case Manager example.
Here is an example of what your test might look like:
- Take a memory reading prior to completing the next step.
- Start three interactions with one service item each.
- Wrap up one of the calls. You now have two active calls.
- Add another call with two service items in that call.
- Wrap up the first call.
- Wrap up the second call.
- Add two new calls with one service item each.
- Add two new calls with one service item each. You now have a total of five open calls.
- Wrap up the first two calls.
- Wrap up the next three calls.
The difference in memory reading between the first step and the last is the leaked memory amount. Perform this test for each of the browsers that you support.
It is important to consider the number of interactions customer service representatives perform during a work day. They should be able to comfortably complete a work day without experiencing browser crashes or sluggishness because of high memory usage or memory leaks. If you find during testing that you cannot complete a standard number of interactions that would be processed in a work day, then the memory leak needs to be addressed. Note, as stated below, that Internet Explorer 11 is the least optimal browser when it comes to managing memory.
Comparisons between browsers
After you have taken the memory readings, you will notice that Chrome, Firefox, and Microsoft Edge perform better with regards to releasing memory compared with Internet Explorer 11. You might also notice that Internet Explorer 11 becomes sluggish as you add more active calls or cases. Internet Explorer 11 runs as a single process on your operating system, while other modern browsers spawn multiple processes and the operating system does a better job allocating memory across these processes than on a single Internet Explorer 11 process.