Well, one reason is to move DSO traffic from the public fast/list threads. If DSO gets backed up and starts queuing operations, it can really slow down the users if it is sharing the fast/list threads, at least that is my experience. Configuring private threads allows tuning of user operations (i.e. public fast/list threads) and separate tuning for DSO (i.e. private threads).
Also applies to API integrations, but haven't done a ton of that with private threads, so I'll leave the detailed explanation to others. Cheers, Richard --------- Richard Baird Mono Solutions Inc. [EMAIL PROTECTED] 416-523-8290 -----Original Message----- From: Jarl Grøneng [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 19, 2006 2:17 AM Subject: Private RPC process(queue) 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
