Some of the reasons we've used private queues are: - Email Engine - We have one thread in this queue for each mailbox. With 60,000+ emails per day its nice knowing that work won't take up end user's threads. - DSO - We have one thread for each DSO Pool. Same reason as with emails. - Reporting - We had several hundred Crystal Reports hitting production so we put those all on their own queue. We've since gone with a dedicated reporting server.
One could argue that you never need any if you just increase your Fast/List. But its nice knowing that a busy process won't consume all your users threads and that busy users won't consume all of your other process's threads. Chad Hall (501) 342-2650 -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Axton Sent: Wednesday, September 19, 2007 9:30 PM To: arslist@ARSLIST.ORG Subject: Re: Dedicated Queue for Mid-Tier 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" ************************************************************************* The information contained in this communication is confidential, is intended only for the use of the recipient named above, and may be legally privileged. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please resend this communication to the sender and delete the original message or any copy of it from your computer system. Thank you. ************************************************************************* _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are"
