Home Analyst Portal - Community

SR130569 - Advice on portal performance

Sean_TerrySean_Terry Customer Advanced IT Monkey ✭✭✭
edited November 13 in Analyst Portal - Community

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?

Answers

  • Matt_Howard1Matt_Howard1 Customer Adept IT Monkey ✭✭
    edited November 20

    @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_RossGeoff_Ross Cireson Consultant O.G.

    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

Sign In or Register to comment.