You can use separate rpc queues to control how much in resources an external process uses. For example, if you have a custom api that will occupy all your fast or list threads that everything else uses, you can create a separate rpc queue to handle the operations of that program. Also, it is handy from a server statistics standpoint in that you can monitor the api calls for each program. In my environment we have separate rpc programs for all external interfaces. Mid-tier, approval server, eie, etc each get their own rpc queue. I have run into issues where a haywire api consumed all fast threads for half an hour, the separate rpc queue at that time would have stopped the outage.
Axton Grams 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
_______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at http://www.wwrug.org
