SR130569 - Advice on portal performance

Sean_Terry

I've seen this issue logged:
https://support.cireson.com/Problem/Edit/PR130511/

We have a few reports of poor performance and I have taken a look at our environment and collected these stats:

FROM [Service Management].[dbo].[WorkItem] - 354,238 total, 217,711 Closed

Is the recommendation to truncate the tables and resync the portal, with the portal now using the archiver?

Matt_Howard1

@Sean_Terry We noticed this recently. Some users were complaining of poor performance, we restarted the services, website, etc. Nothing improved for those users. They cleared browser cache/cookies, etc. I did a check of work items in the ServiceManager DB vs ServiceManagement and found a large discrepancy, similar to your numbers, but only 10-20% of that in ServiceManager. We did the following:

Stop Cache Builder and Platform Cache services.

Run the following against your ServiceManagement DB:
TRUNCATE TABLE LastModified;

TRUNCATE TABLE WorkItem;

Restart Cache Builder and Platform Cache

Wait. 😊

In my instance, the count didn't change. Maybe I didn't wait long enough, maybe the SQL commands failed (ran from PowerShell) who knows? I reran this a second time (did SQL directly in SSMS) and got a more accurate number. Not blaming PS or timing, but after I confirmed the numbers were matched more closely ( I think CacheBuilder was still running ), I sent out the all clear. It may vary for you, but my users said they could tell a difference.

EDIT: I used this KB to guide my efforts:

How To: Completely Re-sync Data with the Cache Builder in the Cireson Portal

Geoff_Ross

Hi Sean,

The next release of the Portal will have a new index to overcome this issue but truncating the table and resyncing is always good because you have less data.

Geoff

Matt_Howard1

@Sean_Terry We noticed this recently. Some users were complaining of poor performance, we restarted the services, website, etc. Nothing improved for those users. They cleared browser cache/cookies, etc. I did a check of work items in the ServiceManager DB vs ServiceManagement and found a large discrepancy, similar to your numbers, but only 10-20% of that in ServiceManager. We did the following:

Stop Cache Builder and Platform Cache services.

Run the following against your ServiceManagement DB:
TRUNCATE TABLE LastModified;

TRUNCATE TABLE WorkItem;

Restart Cache Builder and Platform Cache

Wait. 😊

In my instance, the count didn't change. Maybe I didn't wait long enough, maybe the SQL commands failed (ran from PowerShell) who knows? I reran this a second time (did SQL directly in SSMS) and got a more accurate number. Not blaming PS or timing, but after I confirmed the numbers were matched more closely ( I think CacheBuilder was still running ), I sent out the all clear. It may vary for you, but my users said they could tell a difference.

EDIT: I used this KB to guide my efforts:

How To: Completely Re-sync Data with the Cache Builder in the Cireson Portal

Geoff_Ross

Hi Sean,

The next release of the Portal will have a new index to overcome this issue but truncating the table and resyncing is always good because you have less data.

Geoff