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"
