Shridhar-
I appreciate your thoughts- I'll be running some before & after tests on
this using one of our development/hot-swap boxes, so I'll report the results
back to the list.
A few more thoughts/questions:
> 1. 30 users does not seem to be much of a oevrhead. If possible
> try doing away with connection pooling.
The application needs to scale up gracefully. We actually have about 200
users that could decide to log on at the same time- 30 is just a typical
load. We'd also prefer to have 20,000 subscribers so we can start making a
living with this business <g>.
> 2. While increasing sort memory, try 4/8/16 in that order. That
> way you will get a better picture of load behaviour. Though whatever you
put appears
> reasonable, having more data always help.
I'll try that approach while testing. Is it the case that the sort memory is
allocated for each connection and becomes unavailable to other processes
while the connection exists? If so, since I'm using a connection pool, I
should be able to control total usage precisely. Without a connection pool,
I could start starving the rest of the system for resources if the number of
users spiked unexpectedly. Correct?
> 3. I don't know how this affects on SCSI drives, but what file
> system you are using? Can you try diferent ones?
> 4. OK, this is too much but linux kernel 2.6 is in test and has
> vastly improved IO...
I'm using ext2. For now, I'll leave this and the OS version alone. If I
change too many variables, I won't be able to discern which one is causing a
change. Although I understand that there's an element of art to tuning, I'm
enough of a neophyte that I don't have a "feeling" for the tuning parameters
yet and hence I have to take a scientific approach of just tweaking a few
variables in an otherwise controlled and unchanged environment. If I can't
reach my goals with the simple approach, I'll consider some of the more
radical ideas.
Again, thanks for the ideas- I'll feed the results back after I've done some
tests
-Nick