Hi,
If the Plugin-call comes from a Fast-thread, and the Plugin-callback goes
to a Fast-thread, you will actually tie up two threads in one
User-API-call.
I would just increase the total number of Fast-threads instead of
reserving a new group. At least if you have enough resource in your system
to get rid of most situations where calls are queued.
If not, you may benefit from having very few threads for the
Plugin-callback, as this would tie up less threads total.
Example A: 6 fast-threads, 2 plugin-callback-threads (totaling 8)
4 users doing the Plugin-call would tie up 4 fast-threads and 2
plugin-callback threads, leaving 2 fast-threads for other users to use.
Example B: 8 fast-threads (totaling 8)
4 users doing the Plugin-call would tie up 4 fast-threads plus the other 4
fast-threads when doing the callback. This would leave ZERO threads for
other users.
In example A, users doing the plugin-calls would take longer to complete,
but other users would be less impacted.
I suggest that you do a measurement of how many of your calls are queued.
The old recommendation is to make sure that less than 10% of your
API-calls are queued...
Best Regards - Misi, RRR AB, http://www.rrr.se
Products from RRR Scandinavia (Best R.O.I. Award at WWRUG10):
* RRR|License - Not enough Remedy licenses? Save money by optimizing.
* RRR|Log - Performance issues or elusive bugs? Analyze your Remedy logs.
Find these products, and many free tools and utilities, at http://rrr.se.
> Hi,
>
> Once again I come to ARSlist for guidance. I cannot say how much I
> appreciate all you Remedy experts.
>
> Anyway,
> Our environment is ARS 7.1 patch 3, ITSM 7.0.3, SRM 2.1 and SLM 7.1
> patch 2
> I've noticed that Overview Console loading uses up a lot of SQL time
> (Profiler shows lots of time in overview console)
> I'm pretty sure as the records grow, Overview Console is built
> inefficiently. I can see a lot of LIKE qualifications in the query.
> But i'm no expert if any of this so I could be reading it wrong.
>
> Now we have 50 support staff constantly loading Overview Console to
> look for tickets and I figure that is causing unnecessary load on the
> sql server.
>
> Also we have fast threads as 6/6 and list as 10/10.
> Seems like all overview, SRM workflow go through the fast thread. So
> I'm guessing a lot of actions are queued up waiting for threads to
> free up.
>
> Will a CAI plugin registry private thread of 4/4 help with spreading
> the workflow around?
>
> What does the plugin loopback RPC thread do? What applications use
> that?
>
> Should I decrease the plugin loopback from 2/2 to 1/1?
>
> I just want things to be running as efficiently as possible. But for
> some reason SRM 2.1 seems to be throwing monkey wrenches into
> everything.
>
> _______________________________________________________________________________
> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
> attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are"
>
_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are"
