Re: 3000-4000 users on 7.3.4 -- Any advice?

You'll want to configure MTS and have a sufficient number of dispatchers and server processes to handle the load. Also, if the transactions themselves are rather small you'll want to have the number of transactions per rollback segment higher than the default and you'll want to have enough rollback segments so that no user will ever be blocked on a transaction because there are no rollback segments available.

The exact number of dispatchers/server process is somewhat difficult to guage. If you start out with something like 20 dispatchers and 100 server processes then you can monitor usage to see how many of the server processes are actually getting cpu. Although I can't find any documentation on this, I have found that the server processes with lower numbers tend to get more cpu then those with higher numbers - this leads me to believe that the dispatcher always starts looking for an available server process with the server process that has the lowest value. As the system gets busier the server processes with higher values will start to be used, but if you look at the total cpu you'll see that the lower numbered processes always has a higher cpu usage unless, perchance, some extremely large transaction just happens to get assigned to a server process that is higher on the list.

Ken

Michael Benveniste wrote:

> I'm looking to deploy a third party product that doesn't do any connection
> pooling. As a result, there may well be 3000 to 4000 users connections
> to the database during busy times. The good news is that transaction
> rates are fairly low. The bad news is that I'll probably only be able
> to simulate 1000 users for testing. The target server configuration is
> a Sun 4500 running Solaris 2.6.
>
> 1. Given a constant total number and variety of queries and updates, how
> much worse can I expect the system to perform than with, 1000
> connections? Assume I can cover the memory overhead.
>
> 2. What tuning changes would you recommend for such a beast?
>
> Thanks in advance!
> --
> Michael Benveniste -- mike.benveniste_at_fmr.com
>
> Any comments or statements made are not necessarily those of Fidelity
> Investments, its subsidiaries, or affiliates.
Received on Tue Aug 10 1999 - 11:59:39 CDT