Application Server Topography With Oracle

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 backend 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 backend 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 backend 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: 1. Does your application make extensive use of the back-end database? 2. 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, twoCPU 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.