Carey:
I like this explanation. BTW, I decided to try and set my Mid-Tier to a private RPC. It seems to run much faster when pulling up form data.
I do know that DSO can be and should be configured to use a private RPC socket to speed up transaction time. There is a white paper, available through the Tips and Tricks at the Developer Community page, on why and how to do this.
James McKenzie
L-3 GSI
-----Original Message-----
From: Action Request System discussion list(ARSList) [mailto:[email protected]] On Behalf Of Carey Matthew Black
Sent: Tuesday, September 19, 2006 7:01 PM
To: [email protected]
Subject: Re: Private RPC process(queue)
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. :)
It is my understanding that a private RPC ("server") is different than the "non-RPC specific" behaviour of the ARS server. If your client connects to and uses a private RPC for a given API call then that RPC server processes the call instead of passing it off to the "Fast or List" queues the way a "non-RPC specific" api call would have been handled. The ARS server holds multiple connections to your RDBMS. The exact number is dependent on the number of threads, and private queues you have configured.
I think of it this way...
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:
A ) Allow any vehicle who specified a preferred "express lane"
(private RPC) to get to that private RPC and to be serviced exclusively by that RPC. (All the way to the RDBMS and back.)
If a client does not specify a specific RPC the users request is routed into one of two queue:
B ) Route big trucks (List API calls) into a lane of traffic designed for large data sets and long duration processes.
C ) Route cars (Fast API calls) into a lane of traffic designed for smaller data sets and fast switches.
So if you want to have a client that is sharing the general pool then you do not have to do anything special. But if you want to try to "make sure" that the client is not stuck behind "slow or overloaded"
traffic (other users) then give them a express lane (private queue) and as many threads (lanes of traffic) as your server/RDBMS can support and the client really needs.
However, in a more extreme case, now you could even go as far as setting up a "server group" and simply not putting one of the ARS server behind the load balancer, or limiting who can connect to that specific node and give an entire ARS server to a dedicated client/set of clients too. It would just cost more, but would provide N node architecture too.
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.)
--
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/06, Jarl Grøneng <[EMAIL PROTECTED]> wrote:
> What is the purpose configuring private RPC process(queue)?
>
> If you direct all api calls into 390620 and 390635 (fast and list),
> and let them handle all request with: first come, first serve. With a
> private process you still have to wait for the database to complete
> its operations, and with a good tunes fast/list process I does not see
> any huge performance benefit.
>
> Back in the old days(AR Server on UNIX) with one server process linked
> to one RPC process I can see the benefit.
>
> --
> Jarl
_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at http://www.wwrug.org
