In mid-2015 the Service Manager team began investigating the SM console (henceforth referred to as just “console”) performance issues. We wanted to find ways to improve the responsiveness of the console and we noticed that while the console has a few quirks of its own, there was one way to immediately see an improvement in the console performance.
We took a simple case of opening an active incident from the “All Incidents” view and noticed that it took about 4.5 seconds to open the incident form and display the incident data. The database we used was populated with 69,000+ incidents, with multiple AD connectors bringing in over 150K users and 2 SCCM connectors bringing in 75K computers and the ECL size of over 20.2 million rows.
When we profiled the time taken to open the incident form, we noticed that bulk of the work was done in rendering the UI. It took up close to 60% of the total time.
Further using the Perforator tool, which is part of the WPF Performance Suite, we noticed that the UI rendering was being done in software.
- Here is the link to the x64 bit WPF Performance Suite for Windows 8 and above
- Here is the MSDN link that describes the Perforator tool in detail
Now all WPF applications (including the console) render UI through the DirectX pipeline and have 3 different tiers.
- Rendering Tier 0 - No graphics hardware acceleration. The DirectX version is less than version 7.0.
- Rendering Tier 1 - Partial graphics hardware acceleration. The DirectX version is greater than or equal to version 7.0, and lesser than version 9.0.
- Rendering Tier 2 - Most graphics features use graphics hardware acceleration. The DirectX version is greater than or equal to version 9.0.
To speed up console UI rendering we needed to use Tier 2 rendering. For this we installed the console on a machine that had a GPU (NVIDIA Quadro 600 in our case) and immediately noticed an improvement in the console responsiveness.
| Scenario | Time taken with software rendering | Time taken for hardware rendering |
| Opening an incident | 4.5 seconds | 2.5 seconds |
Opening the same incident from the “All Incidents” view was around 44% faster. Similarly, all other console tasks like opening a Service Request, displaying Administration options, opening configuration item etc. saw an improvement in performance.
These gains were noticeable with remote desktop scenarios also. When the host machine (to which one is connecting to) has a GPU, similar improvements were noticed (discounting the network lag) since the bitmaps on the host machine were rendered faster.
It should be noticed however that the performance of SM console is a function of two things,
- The performance of the SM database
- The performance of UI rendering
If using a GPU on the console doesn’t improve performance considerably then you might want to look at the SM database. The UI rendering can be quick but if a lot of time is being spent in getting the data from the database, the console responsiveness would still be poor.