[sims] Anybody use Intouch? Server getting hammered since Summer update

[Eric_Bisto]

Now the new term is in full swing i've been getting reports that SIMS.NET the client is quite slow, which I am seeing for myself. Some screens load quickly, others take a noticeably long time to appear.

 

I've been doing some monitoring on the server using perfmon and SQL profiler and my investigation seems to identify the culprit to be the "sims.itc_pix_MyMessagesWidget_Load" stored procedure. The average execution time of the query is around 2500-3000 milliseconds, but what i think is causing the excessive load on the sql engine is the number of reads required for the operation which range from about 250,000 to over 600,000 - this number is (hundreds of) thousands times more than what i'm seeing as an average for most other operations, only a few seem comparable and this procedure seems to be executed on the server every few seconds by all the users who happen to have SIMS open and it's executed by any given user about every 60-90 seconds, give or take.

 

This operation stands out like a sore thumb because many other operations occur with less than 50 reads and with significantly less cpu time. It just looks like the number of users using SIMS, leaving it open with the background checking of messages is killing the server. I see other stored procedures taking lots of cpu time and requiring many reads, such as sims.sta_pix_BehaviourSummary_Load and sims.sta_pix_AchievementSummary_Load, but these occur significantly less frequently and appear user initiated, sims.itc_pix_MyMessagesWidget_Load just seems to gobble cpu cycles and disk in the background.

 

by any stretch, an operation which happens every few seconds requiring 600,000 reads seems abnormal, especially for something as simple as updating a message widget. This seems to be something which changed in the Summer update as we didn't have this last year.

 

Any other intouch users finding this?

[glennda]

I fairly sure that is the My Messages front end widget on the homepage. I would get in touch with Capita and ask why its hammering the DB.

[Eric_Bisto]

Thanks Glennda,

 

I have indeed reported this case to Capita, but they haven't responded, I'm not really sure what's going on with them at the moment because we have another outstanding issue with SLG users not being provisioned (which, appears not to be just us as another school in the next town has the same problem) but normally they respond the same or next day, this call has been open a week with no further contact. I don't have high hopes for this one, either sadly (i reported it yesterday)

[glennda]

Get @PhilNeal to give them a prod then - a week IMHO is unacceptable especially with the problem it looks like you are having.

[PhilNeal]

@Eric_Bisto Feel free to get in touch or email one of the support desk managers - details are on SupportNet under sticky items. Our new system isn't without issues so its possible that your case is being updated but you can't see the details. What ever it is please get in touch and we'll check things out.

[matt40k]

Isn't there a setting to increase the time it waits before checking for new message - maybe a tempory solution at least

[vikpaw]

@Eric_Bisto - as @matt40k said, the timing may help ease things. I think the default is 30 seconds, at least it was, mine is set to 300. You can increase it up to 3600.

I think it's a per user setting, you'd have to go in as each user click on the spanner / wrench icon for that panel and then alter it.

It won't help first thing when all users go in for the first time, but hopefully, if they close sims and reopen through the day, the larger timeout will create a staggered effect. otherwise you could manually set a stagger as you go and change them.

[jinnantonnixx]

@Eric_Bisto

I'm not clued up on Intouch, but I noticed that SIMS makes frequent use of the tempdb (with lots of INSERT INTO #temptables).

 

Crack open your Acitivity monitor and check the Recent Expensive Queries. If the expensive queries do something like INSERT INTO #sometable you might see a benefit in moving your tempdb tables across to a dedicated disk, if you can, and increasing the number of files used by tempdb.

 

http://sqlzen.wordpress.com/2011/02/26/tempdb-optimization/

Then again, it may be a red herring.

 

From :

Following are some additional configuration and performance recommendations for tempdb:

 

Create the tempdb database on a fast I/O subsystem. Use disk striping to numerous directly attached disks.

 

Separate the disk space dedicated to tempdb from user databases.

 

Create many files to maximize disk bandwidth and to reduce contention in allocation structures. As a general guideline, create one data file per CPU. Each file should be set to the same size. This enables the proportional fill algorithm to distribute the allocation load uniformly with minimal contention.

Edited September 24, 2012 by jinnantonnixx