See below...
On 9/20/06, Jarl Grøneng <[EMAIL PROTECTED]> wrote:
On 9/20/06, Carey Matthew Black <[EMAIL PROTECTED]> wrote:
> Jarl,
>
> I think the flaw lies in this part of your statement:
>
> "
> > With a private process you still have to wait for the database to complete
its operations
> "
>
> Sure if your RDBMS is to busy to talk to any of it's clients then ARS
> is dead in the water too. However we are talking about tuning the
> application server, not the RDBMS with ARS private queues. :)
Who mention only tuning the application server? Since threads crating
connections to the database you need to include the database in you
tuning approach.
> The ARS server has a traffic cop. The job of this cop is to identify
> the type of traffic that they are looking at and get it processed as
> fast as possible. This is done by following a small set of rules like
> the following:
Yes, this is with default setup with fast/list thread. So with this
dispatcher thread sitting there and route request it is doing this the
most efficient way.
Moving fast operation to fast thread, and heavier operation to the
list thread. I expect the list thread to execute the operation more
efficient, and if you sending all operations into one queue with no
list/fast you does not get the benefit with list/fast operations.
My understanding of a private RPC queue is that it does the function
of a Fast AND List operations as needed by the Client API calls that
are routed to it. So the question becomes the how the volume of
threads in the private queue and the volume of client API calls made
to those threads. (and the length of time each call takes too.)
The real point however, is that a user of a private queue only has to
"wait" on other users of that private queue.
So if you write a single threaded API client and connect to a private
queue (from one and only one client program at a time.) then you only
need a single threaded private queue and your client will NEVER be
waiting for anyone else API calls to finish before it's calls can be
processed. (one lane of traffic with only one car in the line)
If you write a 3 threaded API client then you can connect to a three
threaded private queue (from one and only one client program at a
time) then your client will NEVER be waiting for anyone else API calls
to finish before it's calls can be processed. (three lanes of traffic
with only three car in the lines)
If however you do not specify a private queue then all of the clients
request "fight" for access to a Fast or List thread as they become
available. If some other client usage spikes [ Like one DUMB user
doing unqualified searches, click stop search, redo unqualified search
and repeat a few dozen times in a row] then the other clients waiting
for those same lanes of traffic (shared threads) get to wait for the
RDBMS to answer the multiple unqualified searches that the user is not
even waiting on anymore!
Yes if users start using private queues (when they should not be) then
they could cause your private queue users the same issues. But few
users ever try to mess around with such matters. To my knowledge there
is no way to restrict users (in the ARS permission model) to being
able to only use a private queue or not being able to use a private
queue. Which sounds like an enhancement idea for
"Disable-Client-Operation" (or something like that.)
--
Carey Matthew Black
Remedy Skilled Professional (RSP)
ARS = Action Request System(Remedy)
Love, then teach
Solution = People + Process + Tools
Fast, Accurate, Cheap.... Pick two.
<snip>
--
Jarl
_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at http://www.wwrug.org
