Constrained Server Topography with Oracle's Application Server
10g
by
John Garmany
Before
building your Oracle Application Server 10g
production system, you have a number of decisions to make. What
load will your application place on the server and can the
server handle that load? How many servers will be in your
topography? Which components will you install on which servers?
What is your tolerance for downtime?
If you
follow application server best practices, you will need at least
four servers for the application server, and that does not
include the back-end database. The basic installation includes
the Web cache on server one, two middle tiers on server two and
three, and the infrastructure on server four. This allows for
load distribution, but there are two single points of failure;
namely, the infrastructure and the Web cache. This article will
discuss installing Oracle Application Server 10g
and the supporting back-end database on less than four servers.
You might ask, why would I do this? The answer is, because that
is what most people do.
Single
Server
To
start, we will discuss what most believe is the simplest server
topography (about which I vigorously disagree), a single server
for all components. By single server, I mean one server, usually
with 2 — 4GB
RAM
supporting an Oracle9i or 10g
back-end database, and the entire EE edition of Application
Server 10g.
Truly a single point of failure!

Figure 1:
Single server.
This
configuration is obviously the minimum, and it provides the
minimum capability. A quick look at the installation documents
will tell you that the Forms/BI install should not even fit on a
single server with less that 2GB, yet I have seen a number of
these installations. This configuration guarantees that the
sever will need to page during operations, significantly
impacting response time. On one client's Linux server (single
cpu/1.5GB
RAM)
the Application Server 10g
and the database 10g
used 15 percent CPU without any users being connected. While
this configuration minimizes the number of servers, managing
that one server requires extra work. This configuration will not
support many users, nor will it scale to a large application.
Likewise, tuning individual components, like the back-end
database, is virtually impossible because the server is so
overloaded.
Despite
its drawbacks, the single server topography may meet your needs
if the server is powerful enough to handle the load place on it.
If this is the configuration you have selected there are a
number of configuration options that can reduce the server load.
First, install only what you need. Many of my clients have too
much application server. In one case, the client was running the
Enterprise Edition of 9iAS to support a mod_plsql application.
This
application ran on the Oracle HTTP Server (OHS) and connected
directly to the back-end database. The infrastructures,
mid-tier, SSO, all the other components of 9iAS were not being
used. In fact, the Oracle database comes with an OHS server that
supports Jserv and mod_plsql. This client did not even need the
application server. By shutting down all the components except
OHS, the server suddenly had memory to expand the database, and
application performance jump dramatically.
So here
are some lessons learned from this experience: Don't install,
monitor, and maintain components that you are not using. If you
are only using J2EE, don't install the infrastructure. Next, get
rid of the Metadata Repository database. Oracle promised to
allow you to load the Metadata Repository into the back-end
database, and now they have come through on that promise (refer
to
my earlier article on DBAzine on loading the MR into an
existing database). This removes the 9iR1 database previously
required to support the metadata repository. Lastly, determine
if the Web cache is providing you with any additional
capabilities. On such a constrained configuration, the Web cache
will be small and may not provide you with any real caching at
all. If you find that is the case, simply shut down the Web
cache (or don't install it) and point the users directly to the
OHS port. Figure two shows the foot print of a complete AS10g
install verses the constrained configuration discussed above.

Figure 2:
Two Configurations using a single server.
As you
can see, by eliminating the Web cache and the separate Metadata
Repository, we significantly reduced the memory footprint, and
thus could expand the size of the back-end database and middle
tier (additional OC4J containers or larger memory for the
containers).
Two-server
Configuration
Adding
a second server will allow you to distribute the load and better
optimize the individual components. There are two basic ways to
configure AS 10g
on two servers, and the one you choose will, of course, depend
on you application. Normally, the second server supports the
back-end database. However, that is not always the optimal
solution. What is surprising to many DBAs is that using the
second server to support the Web cache may provide better
application performance. The Oracle Web cache was designed to
reduce the load on the application server components and the
back-end database. By frequently caching server static and
dynamic objects, the Web cache acts as the application server
proxy, passing back only those objects it cannot serve to the
OHS.

Figure 3:
Two-server configuration.
By
installing the Web cache on the second server, you may reduce
the load on the application/database server so much that it is
able to handle the remaining load.
How do
you decide if the database or the Web cache is best for the
second server? Of course, you have to test; there are just too
many variables involved to say one configuration or the other
will always be best for your system. Here are some questions to
ask yourself:
-
Does
your application make extensive use of the back-end
database?
-
After
implementing the Web cache, is there, or is there not a
significant reduction of the load on the back-end database?
If your
application places enough load on the database, either through
SQL or by calling PL/SQL procedures, Java, and so on, you will
probably benefit more by placing the back-end database (with the
Metadata Repository) on the second server. However, I am
assuming that the
back-end database is tuned and that the database load is
resource constraint driven, not SQL tuning, and so on. Likewise,
if your application server is constantly changing information so
the Web cache is not able to effectively cache objects, adding
the Web cache will not reduce the application/database load.
If your
application can be cached to the point that the
application/database server is no longer overloaded, then
placing the Web cache on the second server may provide you with
better application performance. And, the Web cache excels at
caching dynamic objects; if your application dynamically creates
objects that can be effectively cached, the Web cache can
significantly reduce you application/database load.
Finally, my previous discussion about the Web cache is
irrelevant if your application and database are not tuned. It
can take a lot of hardware to overcome bad SQL or an improperly
tuned database. Likewise, a small Web cache will constantly be
aging out objects, requiring them to be replaced by the
application server. Too small a Web cache can be a performance
hindrance rather than help.
Three-server Configuration
Once
you move to three servers, you can take advantage of all the
capabilities of the Application Server 10g
except high availability. A normal three-server installation is
shown in figure 4.

Figure 4:
Three-server configuration.
One
advantage of the three-server configuration is that each tier
can be tuned independently. I still consider the three-server
configuration constrained because high availability and load
balancing cannot be implemented, and each server is a single
point of failure in the system. Again, I would recommend that
the Metadata Repository be installed in the back-end database.
In fact, depending on the application versus database load, you
may want to install the entire infrastructure on the server with
the back-end database.
Server
Discussion
Part of
deciding what is to be your server topography is deciding what
type if server to use. The Application Server 10g
was designed to be deployed on commodity, two-CPU servers with
4GB of RAM. If you are using a Windows OS, you need to use the
Advanced Server version to give AS 10g
access to 3GB of RAM instead of the regular Windows Server,
which will keep 2GB as OS cache and only allow the application
to use 2GB. Also, AS 10g
is a 32-bit application. Although supported on 64-bit systems,
the application server itself is 32 bits with all the
limitations that apply. When it comes to scaling up, the
application server wants more, rather than bigger, servers.
The
back-end database (and the Metadata Repository database) are a
different matter. The Oracle database can scale to many small
servers (Real Application Clusters) or very large multi-CPU
servers. Depending on the database version and the server on
which it is running, the Oracle database can utilize whatever is
allocated to it. However, when it comes to the database, you
should tune before you grow. Many databases consume unneeded
resources because of poor SQL … but that is another discussion.
Summary
This
has been a quick overview of configuring the Application Server
10g in a
constrained server topography. I do not recommend that
production systems use anything less than a three-server
configuration. Many of the systems that I have been called to
work on are one-, or two-server configurations, and it getting
them to perform satisfactorily is always a balancing act. The
key points that I want you to take away are:
1.
Don't install unnecessary components. Know what your application
needs.
2. In a
constrained environment, get rid of the Metadata Repository
database. Load the Repository in the back-end database.
3. Use
the Web cache when it helps. You may get better performance by
connecting directly to OHS.
4.
Match the server to the application it is hosting. AS10g
likes lots of small servers; the database likes 'em small or
large.
My
final point, is don't be afraid to change you configuration.
Many clients have a poorly configured system, but do not want to
reinstall AS10g
to fix it. Time spend optimizing the system now pays off for as
long as you run the server.
Special
for DBAzine.com readers:
"Inside
the Oracle App Server Infrastructure Repository,"
from the new book,
Oracle
Application Server 10g Administration Handbook,
by John Garmany and Don Burleson.