Database Reference
In-Depth Information
Transactions/
Second
Maximum
Concurrency
Concurrent
Users
Figure 5-3.
Concurrent users vs. transactions per second
Initially, as you add concurrent users, the number of transactions increases. At some point, however, adding
additional users does not increase the number of transactions you can perform per second; the graph tends to flatten
off. The throughput has peaked and now response time starts to increase. In other words, you are doing the same
number of transactions per second, but the end users are observing slower response times. As you continue adding
users, you will find that the throughput will actually start to decline. The concurrent user count before this drop-off
is the maximum degree of concurrency you want to allow on the system. Beyond this point, the system becomes
flooded and queues begin forming to perform work. Much like a backup at a tollbooth, the system can no longer keep
up. Not only does response time rise dramatically at this point, but throughput from the system may fall, too, as the
overhead of simply context switching and sharing resources between too many consumers takes additional resources
itself. If we limit the maximum concurrency to the point right before this drop, we can sustain maximum throughput
and minimize the increase in response time for most users. A shared server allows us to limit the maximum degree of
concurrency on our system to this number.
An analogy for this process could be a simple door. The width of the door and the width of people limit the
maximum people per minute throughput. At low load, there is no problem; however, as more people approach, some
forced waiting occurs (CPU time slice). If a lot of people want to get through the door, we get the fallback effect—there
are so many people saying “after you” and so many false starts that the throughput falls. Everybody gets delayed getting
through. Using a queue means the throughput increases, some people get through the door almost as fast as if there
was no queue, while others (the ones put at the end of the queue) experience the greatest delay and might fret that
“this was a bad idea.” But when you measure how fast everybody (including the last person) gets through the door, the
queued model (shared server) performs better than a free-for-all approach (even with polite people; but conjure up the
image of the doors opening when a store has a large sale, with everybody pushing very hard to get through).
Reduces the Memory Needed on the System
This is one of the most highly touted reasons for using a shared server: it reduces the amount of required memory.
It does, but not as significantly as you might think, especially given the automatic PGA memory management discussed
in Chapter 4, where work areas are allocated to a process, used, and released—and their size varies based on the
concurrent workload. So, this was a fact that was
truer
in older releases of Oracle but is not as meaningful today.
