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:

• Initial memory consumption: Caused by the initial load of JavaScript, CSS, and the initial state of the application. This issue typically happens only on initial login and the first time you open a detail screen. For example, in Pega Customer Service™, the initial memory consumption is the Interaction Portal itself and the first time you open a service item. This memory is not released until you log out of the application.
• Application-specific memory consumption: Some screens in a browser-based application consume more memory than others. This issue is caused by the screen requiring more HTML to render or by the screen pulling in a large amount of JavaScript to render. If memory consumption of the screen pushes the browser memory amount close to the 1 GB threshold, redesign the screen to be simpler so that it requires less markup.
• 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.

Memory leaks are the most common cause of high memory usage and browser crashes. Memory leaks can be introduced easily, especially if you use custom JavaScript to extend Pega Platform ™ capabilities. Checking for memory leaks during development ensures that your application has not regressed prior to moving the application to production.

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.

1. Log in to the portal as an end user and launch the Task Manager.
2. Process your case to completion and return to your portal's home screen. Process the case once to prime the system. This step downloads the required JavaScript. It is expected and normal that browser memory usage goes up after processing one case.
3. Record the browser memory in Task Manager.
4. Create and process a case to completion. During case processing, the memory usage goes up. This is normal as additional markup and JavaScript loads, and is not a cause for concern as long as this memory is released when the case is closed.
5. 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.

6. 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:

1. Take a memory reading prior to completing the next step.
2. Start three interactions with one service item each.
3. Wrap up one of the calls. You now have two active calls.
4. Add another call with two service items in that call.
5. Wrap up the first call.
6. Wrap up the second call.
7. Add two new calls with one service item each.
8. Add two new calls with one service item each. You now have a total of five open calls.
9. Wrap up the first two calls.
10. 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.