Poorly performing SCSM 2016 Consoles

David_Darling

Hello experts, since upgrading to SCSM 2016 we're hearing a lot of complaints from our frequent users (i.e. Help Desk) of the SCSM 2016 console around performance.  The complaints are all similar in nature:

1) When typing in the Incident form, the text on the screen is delayed 1-3 seconds from what is being inputted on the keyboard

2) When selecting an item from a drop-down list on the Incident form, the selection (highlighting) of list items on the form is delayed compared to where the mouse cursor currently is

3) When clicking "Add..." button to attach a CI or Business Service on the Incident form, a delay of 10-20 seconds can occur before the list of CI's is displayed and items are selectable

When the user who is experiencing these symptoms closes the console, clears the local type cache, and re-opens the console all of these issues are gone until the next occurrence, which can be hours or days later.

Our users did not experience these issues at all on SCSM 2012 R2.

Anybody else out there experiencing anything similar that might have some insight?  We also have a Premier case open w/ Microsoft but it's very slow moving.

Thanks!

Tom_Hendricks

This may or may not be related, but we are having fairly severe performance problems with SCSM, but only for scoped users.  Unfortunately, that is 99% of our users.  It is worth noting that only admins use the console for configuration in our environment--it is forbidden for all other use.  The portal actually shields our users from some of the performance issues, but since SCSM is directly accessed for certain events (such as saving a ticket), they are impacted at those times.

Our bottleneck is the database.  We also have a support ticket open and are still working through it, but (surprise...) the ECL (Entity Change Log) tables and the user scoping tables are the prime offenders.  They make HUGE memory grabs and had very few indexes applied, as well (literally millions of seeks occurring there).

This was not always the case.  The growth of data is playing a large role in this.  We did not see these issues on 2012 R2 either, but we also had orders of magnitude less data in the database at that point.

There may be other factors to consider in your particular situation, but have them look (with a diagnostic tool that they can give you) at the database.  Whether or not you have enough CPU and RAM and fast enough disk may not actually be what you should be looking at.

Tom_Hendricks

@David_Darling I have provided an update in this other thread that might be helpful for you: https://community.cireson.com/discussion/2795/security-scoping-performance-issues-catalog-item-groups-and-open-form-performance#Item_13

My guess is that MS are covering some of the same things with your ticket, but you never know.