When a ticket is updated on the K1000 (Add Comment, Save, Save & List) it take a minimum of 15 seconds to 1 minute to perform the update. Users and owners are clicking the buttons multiple times cause they don't think it's working then we get multiple duplicate inputs. I only support 350 users with an average 10 tickets a day so the system is not being taxed at all. I don't think we do enough to take it out of sleep mode most of the time. When I open a ticket or if I’m in a ticket, when I click the Tickets tab (no changes made) to go back to the tickets list it is almost instantaneous. Our database can't be that big. We've only been running 8 months.

Thanks.
Russ
0 Comments   [ + ] Show Comments

Comments

Please log in to comment

Rating comments in this legacy AppDeploy message board thread won't reorder them,
so that the conversation will remain readable.

Answers

0
Are you using IE or Firefox? I completely abandoned any hope of using IE for KBOX - it is slow as molasses.

It definitely doesn't sound like your DB is large enough to cause any slowdown. Are you using a virtual KBOX or the hardware appliance?
Answered 09/21/2011 by: airwolf
Tenth Degree Black Belt

Please log in to comment
0
Using IE and the hardware appliance. I've used Firefox and it's almost the same. Makes no sense.
Answered 09/21/2011 by: rjobe
Fourth Degree Green Belt

Please log in to comment
0
How often do your agents check-in? What is the server load (in Agent Settings)? What is your Task Throughput set to?
Answered 09/21/2011 by: airwolf
Tenth Degree Black Belt

Please log in to comment
0
Right now I only have 7 agents running (waiting on the new 5.3 release that just became available) and they are set for 3 hour Run Interval. Current Load Avg. 0.00. Task Throughput is 2.
Answered 09/21/2011 by: rjobe
Fourth Degree Green Belt

Please log in to comment
0
Something isn't right - the box is idle! I'd suggest submitting a ticket so support can scour logs, etc. - they'll probably want to tether to your KBOX.
Answered 09/21/2011 by: airwolf
Tenth Degree Black Belt

Please log in to comment
0
Could be a poorly written ticket rule?

Did you perhaps have an email loop that was never cleaned up?

During that 1 minute what does the "top" output say is taking the lion's share of resources?
Answered 09/21/2011 by: GillySpy
Seventh Degree Black Belt

Please log in to comment
0
I only have three ticket rules which have been used from the beginning. If there is an email loop somewhere I can't see it or don't know where to look for it. What is the "top" output you are referring to and where can I see it?

Thanks.
Russ
Answered 09/21/2011 by: rjobe
Fourth Degree Green Belt

Please log in to comment
0
The "top" output is at settings->support->ts tools. It's one of the tools in the drop down. It's non-interactive so it may take a couple of times to capture it. If you had an email loop (or currently have) you would probably know it, but maybe not.

This query will identify old and current loops that are non-obvious. If you see any big numbers near the top of this results

Select COUNT(ID),HD_TICKET_ID from HD_TICKET_CHANGE GROUP BY HD_TICKET_ID
ORDER BY 1 DESC
LIMIT 50


You may want to call support.
Answered 09/21/2011 by: GillySpy
Seventh Degree Black Belt

Please log in to comment
0
Checked the TS utility Top and during the 'wait' period the load avg was 0.37, 0.16, 0.06 with 161 processes - 2 running, 159 sleeping. The biggest drain was MySQL using 86.82% WCPU (64 threads) at one point. Everything else was using .10% or less.

Russ
Answered 09/21/2011 by: rjobe
Fourth Degree Green Belt

Please log in to comment
0
If it's mysql then my hypotheses stand.

Things to try and / or eliminate:
  • Run my query to check for loops
  • Disable rules and see if it gets better
  • rewrite rules to be more efficient
Answered 09/21/2011 by: GillySpy
Seventh Degree Black Belt

Please log in to comment
0
Ran the query and everything looked good for that. Disabled my ticket rules and found the problem with one of them. We are checking it out now. Will post update when fixed.

Thanks.
Russ
Answered 09/21/2011 by: rjobe
Fourth Degree Green Belt

Please log in to comment
0
A ticket rule was the cause of our slowdown. The rule was rewritten and all is running well (within 3 seconds) now.
Thanks for the help.

Russ
Answered 09/23/2011 by: rjobe
Fourth Degree Green Belt

Please log in to comment
0
Good to hear. What was the problem with it? Subquery in where clause? Subquery on large table with group by? If you don't mind posting the before and after that may help others.
Answered 10/01/2011 by: GillySpy
Seventh Degree Black Belt

Please log in to comment
Answer this question or Comment on this question for clarity