Release 2 (9.0.2)
Part Number A90852-02
 Home |
 Solution Area |
 Contents |
 Index |
| Oracle9iAS Portal Configuration Guide Release 2 (9.0.2) Part Number A90852-02 |
|
A Web portal provides an organized, personal view of business information, Web content, and applications drawn from a variety of sources, including those outside the portal itself. Oracle9iAS Portal is designed to help you create Web portals that enable users to manage, access, and interact with this information, all from a common entry point. You can build any size Web portal, from a small departmental site, to a company-wide intranet, all the way to an Internet deployment that allows enterprises to share information with thousands of subscribers.
After your development team has built your Web portal, the next step is to deploy a production version of it. Successful deployment means that end users are able to access contents in a timely manner, without delays, errors, or server downtime. Because Oracle9iAS Portal can be installed in a variety of configurations on different machines, a successful deployment ultimately depends how you configure Portal to address the requirements of your site.
While designing your configuration, you should identify goals that you want your system to achieve, for example:
This chapter provides information on various deployment configurations. It contains the following sections:
As shown in Figure 5-1, an Oracle9iAS Portal installation contains these components:
You can install multiple instances of any of these components on multiple servers, then connect the servers to suit your needs. Deployment configuration options for Oracle9iAS Portal range from installing everything on a single machine to multi-tier configurations in which the pieces comprising Oracle9iAS Portal are located across multiple servers. Before you begin, it's important that you understand how Oracle9iAS Portal components work together.
|
See also:
Oracle9iAS Portal Architecture Overview located on Oracle Technology Network (http://portalcenter.oracle.com) |
Each time a user requests an Oracle9iAS Portal page, the page is dynamically assembled and formatted according to the portlets and layout chosen for that page. Keep in mind that the parts that comprise the page are typically drawn from a variety of sources. For example, the page's layout, look and feel, and user customizations are stored in the database as part of the overall page definition, completely separate from any page content. This information may, in turn, be cached by the middle-tier.
The HTML portlets that appear on the page can be written in PL/SQL or Java. If PL/SQL, the source of the portlet is the Oracle9iAS Portal database. This could be the database where the current instance of Oracle9iAS Portal is installed, or some other Portal database located on a remote server. If written in Java, a Web provider provides the portlet from some location accessible through the Internet. For example, you could create a Portal page that displays portlet content from an external Web provider and another portlet, containing a chart, that you created using Oracle9iAS Portal.
As shown in Figure 5-2, when a user requests a Portal page, the request is forwarded from the user's browser to Oracle HTTP Server, the middle-tier listener. If the incoming request is to display a Portal page, the listener hands the request off to the Parallel Page Engine (PPE). The PPE then sends requests, in parallel, to the page's various portlet providers to execute the portlets and then assembles the page from the resulting portlet content.
If the request is to execute a PL/SQL procedure, the listener hands it off to mod_plsql, which forwards it to the Oracle9iAS Portal database.
In the simplest configuration, all of the component pieces described in "Oracle9iAS Portal architecture overview" could be set up on a single machine. A single database could reside on the machine, containing separate schemas for Oracle9iAS Portal, OID, and SSO as shown in Figure 5-3.
This configuration would work nicely in a small development environment in which your developers are using Oracle9iAS Portal's declarative interface to build pages, portlets and applications. It could also easily support a small deployment of the finished Web portal.
If you expect to deploy a larger site that delivers more content to more users, you'll need more than a single server or the simple configuration shown in Figure 5-3.
As with any Web portal, the server and database capacity you'll need to deploy a portal built using Oracle9iAS Portal largely depends on the number of user requests for pages that you anticipate. Displaying a single page to a user may require many separate transactions, from verifying whether the user has permission to view the page, to loading the images that appear on the page, to calling a style sheet that contains formatting information for the page.
The upper and lower limits of what you'll need are determined by how you expect your users to use the portal. At a minimum, you'll need enough server capacity to satisfy the average load during a work day, with response times that are acceptable to your user base. If possible, you should strive to satisfy the volume of page requests you anticipate during peak intervals of high user activity. Hardware resources such as CPU, memory, I/O capacity, and network bandwidth are key to reducing response times. Unless you install Oracle9iAS Portal on a server or group of servers that can handle a large number of transactions, your users are probably going to experience slow response times.
The same is true of your database. If you have many applications competing for the same database resources, your Web portal performance may suffer. You can install multiple instances of Oracle9iAS Portal in the same database, for example, a production instance for developing new pages and portlets, and a separate instance for deploying your finished Web Portal. You need to consider whether your database can satisfy requests from both instances in a timely manner.
Adding more servers and database capacity will certainly improve your Web portal's performance, but unless you have unlimited funds at your disposal, you'll need to balance good performance against the costs associated with each new piece of hardware and software.
If a single machine configuration will not suit your needs, you should consider moving the various pieces of the Oracle9iAS Portal architecture to other machines. A rule of thumb when configuring your Web portal is: the larger the site, the more servers you'll require, each server performing more specialized work. Adding extra hardware increases performance. Adding more software instances supports redundancy.
Deployment options for configuring larger Web portal sites include:
These tasks should be performed in the above order until you are satisfied your configuration will handle the demands of your deployed Web portal. If your site needs to handle only a moderate workload, for example, you should first separate the middle-tier from the database, then think about moving SSO to another server. You probably won't need to perform all of the above configuration tasks. But as the site grows, you should expand its underlying configuration by following the sequence shown in the list above.
Before you go on-line with your Web portal, it's a good idea to set up and test a small pilot system. This allows you to gather valuable configuration and tuning information based on real usage patterns, without affecting the users you eventually plan to serve.
The first thing you should consider when configuring a larger system is installing the middle-tier separately, preferably on a different machine from the Oracle9i database as shown in Figure 5-4.
This frees the database and middle-tier from having to compete for hardware resources such as such as I/O, memory, and disk space. Installing them on separate machines also gives you more flexibility in tuning performance. Tuning parameters, such as those for an operating system, are different than those for middle-tier components such as the HTTP server. Setting a performance parameter for one may not provide optional performance for another.
Oracle9iAS Single Sign-On Server enables Oracle9iAS Portal users to identify themselves to multiple applications by logging into a single page similar to the one shown in Figure 5-5.
Once users have logged into a deployed Oracle9iAS Portal site, they can access these applications from portlets in the portal.
As shown in Figure 5-6, a single instance of SSO can be configured to work with multiple Oracle products, including multiple instances of the Oracle9iAS Portal middle-tier.
The system shown in Figure 5-6 is an example of a distributed configuration. The configuration includes a centralized SSO server supporting multiple middle-tier instances. Moving SSO to its own server gives you the flexibility to tune its performance independently of the database and middle-tier.
In addition, isolating SSO from middle-tier installations ensures greater stability for the entire distributed system. If the machine where a middle-tier is installed fails, the Single Sign-on Server and other middle-tier instances that rely on it to validate logins are not affected.
After you move SSO off to its own server, consider doing the same for OID. In a typical Oracle9iAS Portal configuration, OID works with SSO to validate user credentials. It also keeps track of memberships in Oracle9iAS Portal groups. Like SSO, it's a good idea to install, tune, and maintain OID on a dedicated server insulated from the rest of your configuration.
As your Oracle9iAS Portal system grows, you may next want to provide separate databases for Oracle9iAS Portal, OID, and SSO, rather than provide each with a separate schema in the same database, as shown in Figure 5-7.
All databases could be on the same server if the machine is large enough. If not, consider installing each database on its own server in order to provide adequate hardware resources and enhance performance tuning.
You can add redundant middle-tier instances, each with identical configuration settings, to support the largest Web portals. It's a good idea to install each middle-tier instance on its own machine to make failures more independent of one another.
The middle-tier forwards user requests for portal pages to a database or application provider, then assembles the pages with the returned content. As you add more middle-tier instances to your Oracle9iAS Portal configuration, you increase the number of user requests that can be forwarded and improve the overall performance of your portal. In addition, because the middle-tier performs some processing before forwarding a request, less time is spent sending and receiving data over the network. Database and network resources are used more efficiently.
A distributed Oracle9iAS Portal configuration offers improved performance over a single machine configuration because you are making more software and hardware resources available to the Web portal. But there are other benefits. You can use additional servers and software to provide failover, thus ensuring system stability. And you can deal with wide fluctuations in the amount of work your Web portal is expected to perform over the course of a day using load balancing between multiple servers. Finally, you can add more servers to a distributed configuration in order to support more users, thus providing scalability.
If you anticipate a heavy volume of traffic on your Web portal, you can distribute the load across multiple servers, each with its own middle-tier instance. If one server is overloaded with too much traffic, a second server can handle the overflow.
Oracle9i Application Server provides its own load balancing capability by pooling server instances to service incoming requests. If one instance does not respond, then the request is forwarded to another instance. This ensures that content and applications are always available to users of your deployed site.
For very large sites, you can add a Load Balancing Router (LBR) to distribute incoming requests to the middle-tier servers, as shown in Figure 5-8. An LBR is a very fast network device that distributes Web requests to a large number of servers. It provides users of your Portal with a single published address, instead of them having to send each request to a particular middle-tier server.
My.Oracle.com (MOC) uses a BIG-IP router to sort requests. Because the software logic for distributing loads is contained in the LBR itself rather than installed separately on each individual middle-tier server, an LBR lowers the overall administrative costs of your configuration. MOC is both an intranet and extranet Web site. It provides Oracle customers and employees with a single customizable entry point to all of Oracle's on-line services as well business information from external providers such as NASDAQ and Business Week.
Adding an LBR can also help your configuration deal with load variations. Users may access your site, use its applications, and request content at a much higher frequency during certain peak intervals, for example, between 9 AM and 10 AM when most users log on to begin their work day. During these periods of heavy traffic, the LBR can distribute page requests among the various middle-tier instances to ensure quick response times.
If your peak load occurs on a regular basis, consider a configuration that specifically addresses the need to handle peak load requirements. If your peak load is infrequent, you may be willing to tolerate slower response times at peak intervals rather than spend additional money on hardware.
Note that the LBR itself can be configured to support failover. The My.Oracle.com configuration in Figure 5-8 could add a second BIG-IP router, which would be available in case the primary router fails.
Failover is the ability to switch to backup when part of your system fails, such as a server or database. When an Oracle9i database fails, for example, it restarts using any preserved state information from the backup.
Redundancy is the technique of providing duplicate machines configured identically. The redundant machines provide enough capacity to service requests, and provide backups in case of failures and errors. You implement redundancy by increasing the number of machines in your configuration. One server is typically active while the other monitors the first server's activity, ready to take over if it fails.
As shown in Figure 5-9, My Oracle.com provides for failover using an additional middle-tier server that can take over if any of the other servers encounters problems that cause it to fail.
To set up redundant middle-tier instances, you configure the original and each redundant instance with identical server name and server port entries, for example, my.oracle.com and port 5000.
One alternative to redundancy is to failover by using any excess capacity that you have in your overall configuration. For example, you might have four middle-tier servers, each running at 75% capacity. If one server fails, the other three can take over the workload of the fourth (25% X 3 = 75% capacity of the failing server).
Scalability is the ability of a Web portal to handle more requests as the number of users and the volume of content increases over time. As the portal handles more traffic, users should not notice any change in performance, as measured by response intervals and frequency of errors. If scalability is your goal, you need a flexible configuration that will allow you to add database capacity and servers incrementally as needed without adversely affecting the rest of your configuration.
When My.Oracle.com (MOC) was set up, for example, it was initially expected to serve approximately 40,000 Oracle employees. The user base is anticipated to expand eventually to a million and a half, most of them users of the Oracle Technology Network (OTN), each automatically provided with an MOC account.
Oracle9iAS Portal uses three methods to cache Web pages and content.
To increase the availability and scalability of medium to large deployments, consider configuring multiple instances of Oracle9iAS Web Cache to run as members of a cache cluster. A cluster is a collection of cooperating Oracle9iAS Web Cache instances that work together to provide a single logical cache. Cache clusters provide failure detection and failover, increasing the availability of your Web site. If an Oracle9iAS Web Cache instance fails, other members of the cache cluster detect the failure and take over ownership of the cached content of the failed cluster member.
By distributing the Web site's content across multiple Oracle9iAS Web Caches, more content can be cached and more client connections can be supported, expanding the capacity of your Web site. You make use of the processing power of more CPUs and, because multiple requests are executed in parallel, you increase the number of requests that are served concurrently
In addition to providing failover, an Oracle9iAS Web Cache cluster also balances the load it forwards to the middle-tier.
In Figure 5-10 , the LBR distributes incoming requests to the three Oracle9iAS Web Cache instances. Each instance determines if the request matches on already in the cache. Because the instances in the cluster communicate with one another, all three instances are checked for the cached content. If there is a match, the cached content is returned to the Browser. If not, the request is forwarded to the middle-tier.
To take advantage of Oracle9iAS Web Cache's clustering capability, you must configure each instance as a member of a cache cluster. It is recommended not to use "sticky routing" in this configuration. Enabling sticky routing in the cluster would mean that requests from one Oracle9iAS Web Cache instance for a given user always needs to be sent to a particular middle-tier. This would prevent effective load balancing between the middle-tiers and also minimize the shareability of content in the cluster. In this setup there is no one-to-one relationship between an Oracle9iAS Web Cache instance and a matching middle-tier instance. As shown in Figure 5-10, Oracle9iAS Web Cache 1 provides load balancing between middle-tiers 1, 2, and 3. Oracle9iAS Web Cache 2 and 3 do the same.
To take advantage of Oracle9iAS Web Cache's load balancing capability, you must configure each instance as a members of a cache cluster. "Sticky routing" means that certain types of requests are always forwarded from a Oracle9iAS Web Cache instance to middle-tier server. It is recommended not to use "Sticky routing" in this configuration, because in a clustered configuration, there is no one-to-one relationship between a Oracle9iAS Web Cache instance and a matching middle-tier instance. As shown in Figure 5-10, Oracle9iAS Web Cache 1 provides load balancing between middle-tiers 1, 2, and 3. Oracle9iAS Web Cache 2 and 3 do the same.
As a rule of thumb, one Oracle9iAS Web Cache instance can balance load across three middle-tier servers. If you need to support more middle-tiers, you can set up additional Oracle9iAS Web Cache instances. For example, Oracle9iAS Web Cache instance 1could provide load balancing to middle-tier servers 1 through 3. Oracle9iAS Web Cache instance 2 could provide it to middle-tier servers 2 through - 4, instance 3 to middle-tiers 3 through 5, etc.
|
See also:
|
If you have multiple middle-tiers in your configuration, you have the option of setting up the Oracle9iAS Portal Cache for each middle-tier on a shared file system. This ensures that each middle-tier can share cached content, rather than each drawing from its own independent cache.
For example, one middle-tier might handle a request for an item by caching it in the Oracle9iAS Portal cache. Because you typically use a load balancer for configurations having multiple middle-tiers, the next request for the item could be handled by a different middle-tier. This middle-tier could access the cached version if Oracle9iAS Portal Caches for each middle-tier are shared on a common file system.
Oracle9iAS Portal can be configured to use Secure Sockets Layer (SSL), which provides security between browsers and servers. The Oracle9iAS Portal middle-tier as well as Oracle9iAS Single Sign-On Server can run in HTTPS mode.
Depending on how you set up your configuration, you can use SSL to address the security needs of your Web portal as well as optimize its performance. For example, if you are mainly concerned with protecting user login credentials, consider running your Oracle9iAS Single Sign-On Server instance in HTTPS mode, which provides encryption and requires some overhead to support. Run instances of the middle-tier and Oracle9iAS Portal in HTTP mode.
You may also want to encrypt the traffic between servers, and between servers and databases. For example, you might have a database that contains sensitive payroll data. In this case, you can run each middle-tier handling sensitive data in SSL mode.
One problem with this configuration is that you are supporting SSL on multiple servers. As the configuration shown in Figure 5-8 indicates, you can set a Load Balancing Router outside your company's firewall while keeping your middle-tier servers inside. The LBR in this configuration will handle the Web traffic to and from your servers. LBRs such as the Big IP router that My.Oracle.com can add an SSL accelerator card that secures all data transmitted outside the firewall. An advantage of using this card is that it handles traffic much faster than would SSL software.
After you set up the basic configuration of your Portal system, you are ready to tune performance based on the configuration. One way to optimize performance is to set the approximate number of simultaneous Web requests that your portal can handle. You can do this by setting options in the HTTP Server and Parallel Page Engine.
Oracle HTTP Server processes Web requests by distributing them to HTTP processes. HTTP Server can serve all types of requests originating in users' browsers, such as those for static files, Java servlets, or PL/SQL procedures.
MaxClients is an HTTP Server configuration directive that controls the maximum number of Web requests that the HTTP Server can handle at any given time. When the MaxClients value is exceeded, the HTTP Server refuses to handle any new requests until it handles the current load and the HTTP processes are freed. In fact, client browsers may be "locked out" if the number of allowable sessions has been exceeded by other browsers.
One way to think of the MaxClients directive is that it's a throttle that permits just the right flow of concurrent Web requests to your server. Set it too low, and your Web portal performance may suffer. Even though you may have the server and database resources to handle more traffic with quicker response intervals, Web requests can't get through because you haven't set enough processes in MaxClients.
Setting MaxClients too high unnecessarily consumes resources, because each http process server consumes resources such as CPU time, memory, and I/O. And it may result in poorer rather than better performance. Why? Keep in mind that the HTTP Server can handle all sorts of requests, including those for PL/SQL procedures. When the HTTP Server receives such a request, it hands it off to mod_plsql to communicate with the Portal database. For each request, mod_plsql opens a database connection. The value you set for MaxClients, therefore, sets the upper limit of database connections that mod_plsql can open.
Say you set MaxClients to the maximum number, 1024. At any given time, the HTTP Server is ready to handle 1024 simultaneous Web requests, including a number that require database connections. Even if your server is large enough to deal with this, the database to which it is connected may not be. And if the ratio of requests for PL/SQL procedures versus other types of requests suddenly becomes very high, you risk overloading your database.
The key to good performance is determining the number of Web requests the servers in your configuration can process as well as how much traffic your database can handle. So if your Portal configuration includes multiple middle-tier servers connected to a single database, the number of possible Web requests you can handle is probably going to be limited more by database capacity than the middle-tiers.
|
See also:
|
MinSpareServers is an HTTP Server directive that sets the minimum number of idle sessions. An idle sessions is one that is not currently handling a Web request. If the number of idle sessions is fewer than the number specified in MinSpareServers, new processes are created at a maximum rate of 1 per second.
You should consider tuning this parameter only on very busy sites. The default setting is 5. Setting this parameter to a large number is almost always a bad idea. A rule of thumb is to set MinSpareServers at a little over the average number of Web requests your Portal typically handles. Ideally, you can set it so user requests are filled all the time by open ports without having to open a new one, but this is possible if you have the database resources to support a lot of ports.
|
See also:
Oracle HTTP Server Administration Guide in the Oracle9i Application Server documentation library. |
As described in "Assembling Oracle9iAS Portal pages", a request for a Portal page originates in the form of a URL sent from a user's browser to the HTTP server. If the request is for a Portal page, it is forwarded to Parallel Page Engine (PPE). The PPE then asks each Web provider that owns a portlet on the page to execute the portlet and return content to the Portal page.
The PPE uses a pool of fetchers to forward requests over the Internet to Web providers and wait for data to be returned. Once it is finished with the request, the fetcher is available to handle another new request.
Pool size is an optional PPE setting that determines the number of fetchers available at work at any given time. If the maximum is exceeded, new URL requests are placed in a queue waiting for a free PPE fetcher.
The default setting is 25. For most Web portals, you should never have to change pool size. But keep in mind that if pool size is too low, the user notices that pages take too long to draw at peak periods. If pool size is set too high, a possible resource drain may occur because too many concurrent URL requests can overwhelm the PPE.
|
See also:
Oracle HTTP Server Administration Guide in the Oracle9i Application Server documentation library. |
|
 Copyright © 2002 Oracle Corporation. All Rights Reserved. |
|
