Well stated. The only 'real' justifications I've had for using private queues are: - When I had an api program that consumed all the fast/list threads. By using a private queue for this, we were in essence throttling the api and leaving the fast/list resources available for normal operations. - When I needed to collect statistics on a given queue
Axton Grams On 9/19/07, Carey Matthew Black <[EMAIL PROTECTED]> wrote: > I would also add that... > > Jarl is correct that more resources are needed to run more Server > threads. But the question is does your ARS server hardware (and DB > hardware) have more resources to give? If yes, then more threads will > allow more concurrent traffic through the whole chain. If no... then > adding more threads will slow down the existing threads too. > > > On the other side of things.... > > One of the main points of a "Private" server queue is to prevent other > clients/users from getting in the way. So if you have your "uneducated > users" using the general pool of fast/list threads and you have 3 > separate mid-Tier servers that you do not want to be blocked by your > "uneducated users" then you could setup a private server per Mid-Tier. > This would prevent the Mid-Tier's from waiting on each other or the > "other users". > > If you know that Mid-Tier #1 is configured for 10 concurrent users > then that private server might only need 2 or 4 threads total. However > if Mid-Tier #2 is configured to support 2000 concurrent users, well.. > it needs more threads than 4 to support those users. :) > > Also... if you have things like command line programs that do "batch > processing" then you might also want those scripts to connect to a > different private queue so that they are not blocked by Mid-Tier > traffic or "other users" too. > > > > In general I think of it this way.... > > A private queue is like a highway into a city (the ARS server). The > highway can have any number of lanes for traffic (threads). The > limiting factor is how big the city(hardware/network/db) is. If your > city only has one 4 way stop light (a desktop PC) then you likely can > not support 7 independent highways no matter how many lanes each one > has. :) > > > I would advocate that you turn on Server Statistics and watch a few > values to get a feel for your load/needs... ( to name a few) > 'ARServer Idle Time' > 'Network Responding Time' > 'Number of Threads' > 'Num Queue Items Blocked Count' > 'Queue Items Blocked Count' > 'Restricted Read Only Connections' > 'Read Only Lic Connections' > 'Floating Write Lic Connections' > 'Fixed Write Lic Connections' > 'Number of Current Users' > > If your stats are "per individual queue" then you will have a better > idea of how these things break down by queue too. > > > HTH. > > -- > Carey Matthew Black > Remedy Skilled Professional (RSP) > ARS = Action Request System(Remedy) > > Love, then teach > Solution = People + Process + Tools > Fast, Accurate, Cheap.... Pick two. > > On 9/19/07, Jarl Grøneng <[EMAIL PROTECTED]> wrote: > > ** > > If you set up a private queue for mid-tier to increase performance, > > would'nt you then loose performance some other place? > > The total number of requests the server is capable to perform should still > > be the same.... > > > > Otherwise; pertum mobile... > > > > -- > > Jarl > > > > > > > > > > On 9/19/07, Hall Chad - chahal <[EMAIL PROTECTED] > wrote: > > > ** > > > > > > > > > > > > For all practical purposes, any queue can do any type of work. So, yes > > > you lose the ability to split up your Mid Tier traffic into submit/update > > > type work (Fast) and query work (List), but that distinction is not > > > important. The important thing is the work gets done, and any private > > > thread can do any of the work. > > > > > > > > > > > > Just make sure that you have enough private threads to handle the max > > > number of concurrent operations you expect to have. To gauge this you > > > should consider what percentage of your users will be coming in through > > > Mid Tier. If, for example, you have 5 Fast and 5 List, and 50% of your > > > users access the system through Mid Tier, then you could probably go with > > > 5 private threads. > > > > > > > > > > > > I would advise starting with some rough estimate like this. Then capture > > > API and SQL logs from your peak time and run them through BMC's Log > > > Analyzer. That will break down thread activity levels. If you see that > > > any of your private threads had a min idle time of 0, then there was some > > > queuing of API calls and you may want to increase the number of threads. > > > If there is no queuing, or if it only occurred a couple times, then > > > you're probably okay. That's also a good routine to use when estimating > > > Fast and List thread limits. > > > > > > > > > > > > > > > Chad Hall > > > (501) 342-2650 > > _______________________________________________________________________________ > UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the > Answers Are" > _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are"
