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.
List thread are also using more memory than a fast thread.
Obviously the more thread/queues your running the more Resources your
need on the ARS server too. (RAM/network bandwidth/CPU, etc..)
And just as a minor nit....
I have never tried to direct traffic specifically at 390620 OR
390635, but I would expect the ARS server to IGNORE that requested
path and "do the right thing" based on the API call that was being
made instead. ( I could imagine bad things happening on the ARS server
if you managed to queue a LIST API call on the FAST server. Not sure
the other way around would be as much of a problem, but maybe it would
be too.)
If you do a getentry from 390635 its still routed to 390620 as a fast operation.
--
Jarl
_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at http://www.wwrug.org
