05.11.2015 Views

Apress.Expert.Oracle.Database.Architecture.9i.and.10g.Programming.Techniques.and.Solutions.Sep.2005

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

CHAPTER 5 ■ ORACLE PROCESSES 167<br />

Of course, a big reason to use shared server is when you have no choice. Many advanced<br />

connection features require the use of shared server. If you want to use <strong>Oracle</strong> Net connection<br />

pooling, you must use shared server. If you want to use database link concentration between<br />

databases, then you must use shared server for those connections.<br />

■Note If you are already using a connection pooling feature in your application (e.g., you are using the<br />

J2EE connection pool), <strong>and</strong> you have sized your connection pool appropriately, using shared server will only<br />

be a performance inhibitor. You already sized your connection pool to cater for the number of concurrent<br />

connections that you will get at any point in time—you want each of those connections to be a direct dedicated<br />

server connection. Otherwise, you just have a connection pooling feature connecting to yet another<br />

connection pooling feature.<br />

Potential Benefits of Shared Server<br />

So, what are the benefits of shared server, bearing in mind that you have to be somewhat careful<br />

about the transaction types you let use it? Shared server does three things for us mainly: it<br />

reduces the number of operating system processes/threads, it artificially limits the degree of<br />

concurrency, <strong>and</strong> it reduces the memory needed on the system. We’ll discuss these points in<br />

more detail in the sections that follow.<br />

Reduces the Number of Operating System Processes/Threads<br />

On a system with thous<strong>and</strong>s of users, the operating system may quickly become overwhelmed<br />

when trying to manage thous<strong>and</strong>s of processes. In a typical system, only a fraction of the thous<strong>and</strong>s<br />

of users are concurrently active at any point in time. For example, I’ve worked on<br />

systems recently with 5,000 concurrent users. At any one point in time, at most 50 were active.<br />

This system would work effectively with 50 shared server processes, reducing the number of<br />

processes the operating system has to manage by two orders of magnitude (100 times). The<br />

operating system can now, to a large degree, avoid context switching.<br />

Artificially Limits the Degree of Concurrency<br />

Speaking as a person who has been involved in lots of benchmarks, the benefits of this are<br />

obvious to me. When running benchmarks, people frequently ask to run as many users as possible<br />

until the system breaks. One of the outputs of these benchmarks is always a chart that<br />

shows the number of concurrent users versus the number of transactions (see Figure 5-3).

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!