Oracle9i Application Server Best Practices Release 2 (9.0.3) Part Number B10578-02 |
|
This chapter describes Oracle9iAS Portal best practices. It features the following sections:
In addition to the following, more Oracle9iAS Portal best practices can be found at:
http://portalcenter.oracle.com
On that Web page, click on Product Information
This section describes performance best practices. It features the following topics:
Oracle9iAS Portal provides two different mechanisms of caching to improve performance. These include out-of-the-box integration with Oracle's award winning in-memory cache solution, Oracle9iAS Web Cache, and a persistent file-based cache.
The file-based cache is always maintained at the same time as Web cache, providing redundant cover should the in-memory solution fail. It is also useful for things like persistent sessions. In the future, persistent content may be used for cache warming of Web cache. Further, file-cache performance improvements can be achieved by locating the cache on a RAM Disk.
By default, Oracle9iAS Portal issues dynamic caching instructions to Oracle9iAS Web Cache, to allow caching of default content (e.g. page). The page designer can use the different cache options (whole page, page definition, or none) to ensure that the correct balance is maintained between speedy delivery of cached content and avoiding the delivery of stale content. It is, however, important that the page or portlet designer understand that the degree of dynamism of a web page is inversely proportional to its cachability. Understanding validation, expiration, and invalidation-based caching will help the designer select the most appropriate cache method.
For superior performance, Oracle9iAS Web Cache should be deployed on a dedicated machine - by default, it is installed, configured, and co-located with the Oracle9iAS Portal middle-tier. Review the Oracle9iAS Web Cache best practices for further details.
There are two different types of providers: web provider and database provider. Database providers are implemented in Java or PL/SQL and executed as stored procedures within the Oracle database. The Oracle9iAS Portal middle-tier communicates with these providers in two ways: through mod_plsql, if the provider resides in the local portal database; or by SOAP over HTTP, if the provider resides in a remote database. (In Oracle9iAS Portal 3.0.x, Net8 connections were used in both cases. SOAP over HTTP allows easier communication with remote database providers through firewalls.) Note that execution in the database does not place any restrictions on the functionality of a portlet; database facilities allow for external communication in many ways, including HTTP connections to external content. Database providers are particularly appropriate for portlets that require significant interaction with the database and in situations where the development team has extensive Oracle PL/SQL development experience.
Web providers are implemented in any Web deployment environment (e.g. Java, ASP, Perl) and executed as an application external to Oracle9iAS Portal. Oracle9iAS Portal also communicates with these providers using SOAP over HTTP. Web providers are most appropriate for external information sources (e.g. Internet news/business information) and in environments where developers have experience using Java and other Web development languages.
Oracle9iAS Portal provides a parallel page engine (PPE) stateless servlet that fetches the page meta data, assembles the page, and manages the cache. This is a key component, and its stateless nature allows it to be deployed across multiple OC4J instances.
By default, Oracle9iAS is installed with a single OC4J_Portal instance where this PPE servlet is deployed. From a scalability perspective, it is highly recommended to have at least one other (if not more) OC4J instance with this PPE servlet deployed. Alternatively, you can increase the number of OC4J processes dedicated to this instance. Oracle HTTP Server load balance routing will distribute requests across the multiple instances or processes, providing better scalability for the system.
Oracle9iAS Infrastructure provides important functionality to Oracle9iAS Portal: all the metadata, database providers, etc. reside in the database. Hence, conventional database tuning (e.g. putting portal Indexes on a separate disk) is important. However, it is not recommended to analyze the schema for further fine tuning since this has already been done and CBO (Cost Based Optimizer) used where appropriate.
Moreover, there are also standard ongoing jobs that re-tune the schema based on collected statistics on a regular basis.
Another aspect of tuning is the SQL*NET tuning between the mod_plsql (i.e. Oracle HTTP Server) machine and the database itself. You should also consider Real Application Clusters (RAC) as an option for the availability and scalability of the Oracle9iAS Portal database.
mod_plsql maintains it's own connection pool thus negating the need in most cases for the use of MTS. There are, however, some tuning parameters that can be adjusted to give optimal mod_plsql performance and ensure that processes are not shut down heavily:
STATELESS_FAST_RESET
.
MaxClients=MaxSpareServers=average system
load.
MaxRequestPerchild=10000
MinSpareServer=1
KeepAlive
to off for heavily loaded sites.
Tuning these parameters will affect the performance of Oracle HTTP Server with respect to nonmod_plsql requests. Therefore, if you wish to service other types of requests with the same installation, you can employ a dual listener strategy where you start two Apache listeners, one tuned for standard content requests and one tuned for mod_plsql content requests. Further information about this approach and other factors can be read in the mod_plsql section of the Oracle9i Application Server Performance Guide.
When registering a web provider, it is possible (by selecting a checkbox) to request that session specific information such as session id and user login time be cached for each request. Whilst this is a mandatory requirement for web providers who rely on session information to ensure the validity of atomic transactions, those providers who do not rely on session level information should turn this option off as it improves the portlet cache hit rate.
Portlet execution speed is the average time required to execute all uncached portlets on a page. Since portlets execute in parallel, this measure will be equal to the execution speed of the slowest portlet, plus page assembly overhead.
The portlet execution speed will differ from site to site since each site will have a different mix of content and applications in their portal. Estimating this number will require running your own benchmark tests (if you already have applications that you plan to expose through portlets, you will already have a sense of the execution times). In general, the speed of page assembly will be limited by the execution speed of the slowest portlet on the page (when the portlet output is not cached).
Page security and the number of tabs and portlets on a page will affect the time it takes to generate page metadata. The number of portlets on a page will affect page assembly times in the middle tier especially if each portlet must be contacted for a validity check or content refresh.
Page complexity, a function of page security and the number of tabs, items, and portlets on a page, affects throughput by increasing the amount of metadata that needs to be generated as well as the number of security and validity checks. Page complexity does not affect page assembly time in the middle-tier but may affect the time it takes to validate and refresh portlet content.
One of the ways to evaluate whether the practices mentioned here or elsewhere are effective is to measure the resulting performance, and use the measurements to further fine tune the system.
To get granular results from system internals, append &_DEBUG=1
to the end of the portal page URL you wish to measure performance for. The resultant output is a report from the parallel page engine. It will provide details of performance of each component on the page, whether a cache miss or hit occurred and how long page loading took.
Periodic monitoring of this information will help keep the system fine-tuned for better performance.
This section describes content management and publishing best practices. It features the following topics:
Oracle9iAS Portal allows portal pages to be organized within page groups. The default and easiest way to get started is with a single page group. This has the advantage of being able to easily copy or move content elements across pages within the group.
However, in a larger environment, you may want different people to administer different areas of the site - and this delegation of administration is easier if you separate your site into multiple page groups. Currently, it is not possible to copy or move content elements between page groups, or to use templates, styles, and metadata elements (categories, perspectives, attributes, and item types) owned by one page group in another page group.
Templates, styles, and metadata that need to be used across page groups can be placed in the supplied Shared Object Page Group. In addition, any page can be published as a portlet, which allows the content on that page to be viewed on any other page in any page group.
There are several different ways to organize the set of content that your portal needs to provide to its end users. This organization is referred to as a taxonomy.
You can create a physical taxonomy consisting of pages and sub-pages. You can also create virtual taxonomies consisting of categories and perspectives. Users can browse a taxonomy, which appears as a hierarchy of pages. Each category and perspective page is built dynamically by searching for content belonging to the selected category or perspective when the page is rendered.
Reorganizing the physical taxonomy is easy and can be done by moving pages around within a page group and by moving items between pages (however, pages and items cannot be moved between page groups, as described above). Currently, it is not possible to reorganize categories and perspectives. While content can be reassigned to a different category or perspective, this can be a cumbersome process if you have a large number of items or pages.
Therefore, carefully plan your category and perspective hierarchies before you start to add content to your pages.
Creating pages with Oracle9iAS Portal is easy, and it may be tempting to start adding pages quickly at the onset of your portal development project without first defining page templates. To ensure a consistent look-and-feel to your site and to minimize maintenance effort, it is recommended that you always base your pages on page templates. A template cannot be applied to a page once the page has been created.
It is also a good idea to manage your templates in the Shared Objects page group, as templates cannot be promoted from another page group to Shared Objects.
This also implies that you should define your templates before you create your content page groups, as you will want the root page for your page group to use one of your standard templates. The root page of a page group is automatically created, and you cannot replace the root page with another page.
A page template defines the layout (the placement of item and portlet regions) for pages. A template can also contain content, in the form of portlets and items that you want to appear on all its pages. However, changes made to a template are seen immediately in its dependent pages. Making changes to the content on a template will take some period of time (minutes or even hours, depending on the extent of the changes). During this time, the pages themselves will be in a state of flux as the template is modified. This can have an undesirable impact on your portal users and may require that the affected pages be unavailable while performing template maintenance.
This situation can be avoided by managing template content on navigation pages. For example, use a navigation page to contain the banner for your template, including such elements as the page name smart text, company logo, and various smart links such as the "Customize" icon and the "Home Page" link. When you want to modify the banner, copy the navigation page and make changes to the copy. When you are satisfied with the changes, replace the original banner navigation page portlet on the template with the modified copy. This can be done very quickly and will have minimal impact on portal users. The same recommendation applies to navigation bars, page footers, and other content that you want to include on the template.
One of the big advantages of Oracle9iAS Portal is the ability to define and associate metadata with any content. Oracle9iAS Portal provides three types of metadata:
It is important to understand the characteristics of these metadata elements in terms of their impact on content organization, maintenance, presentation, and search. For example, they all aid in searching for content but have different styles for search submission and for presentation in search results. There are also important differences in terms of how content contributors assign metadata values to content and in how these elements are presented on pages.
The following Table 7-1 summarizes the characteristics of the metadata elements:
Simple Item Types (e.g. Simple Text, Simple File, Simple URL, Simple Image) are very basic item types that contain a minimum number of attributes (the Display Name and the item type's distinguishing attribute, such as the text box for Simple Text and the file upload box for Simple File). Custom item types (including the pre-defined types Text, File, URL, Image, etc.) are based on the simple types but can contain any number of additional attributes and can be modified anytime to add or remove attributes.
While Simple Item Types present a very simple interface for end users to add content, it is important to understand that they cannot be extended to include additional attributes, and you cannot change the type of an item once that item has been created. Therefore, if you anticipate that you will want to add additional attributes to your content, avoid the use of simple item types by following these steps:
Note that items created through the WebDAV interface (Web folders) are always created as Simple File. While WebDAV makes it very convenient to add content from the desktop, that convenience may be offset by the restriction on adding attributes to the Simple File item type. If you need the flexibility associated with a custom item type, create your file items through the Add Item wizard in the browser. Any file item can be edited through WebDAV, even if it belongs to a custom item type. In a future release of Oracle9iAS Portal, you will be able to specify a custom type for items created through WebDAV.
Oracle9iAS Portal provides a set of export/import utilities which enable customers to copy portal content between portal installations. A typical example where these utilities would be used is to copy or update portal page groups and application components between a development instance and a production instance of Oracle9iAS Portal.
The following is a summary of recommendations and best practices developed for Export/Import functionality as provided in Oracle9iAS Portal version 9.0.2.2:
If you are not sharing the same Oracle Internet Directory instance between your source and target systems, Oracle recommends the following procedure for export/import:
If however, you are able to share a single Oracle Internet Directory instance between your source and target systems, we would recommend the following procedure:
Before exporting or importing, ensure that your system meets the minimum system requirements. You will also need to know the following information about your configuration on both your export and import portal environments:
Also, plan to perform the export and import process during non-business hours, and to disable access to Oracle9iAS Portal during the process. To disable access to portal temporarily for all other users, one way is to configure your listener for a different port number during the duration of the export and revert it back to the original port when your export is complete.
Each export or import process sets up a background process. Therefore, verify that the job_queue_processes database parameter is set appropriately.
To check the value of the job_queue_processes parameter, simply perform the following query from SQL*Plus:
select name, value from v$parameter where name='job_queue_processes'
The value for job_queue_processes
should be at least 2 to allow toe execution of background jobs.
An alternative way of checking the job_queue_processes
parameter is to simply examine the init.ora file in your database's ORACLE_HOME
.
Also, for Oracle9iAS Portal version 9.0.2.2, please be sure to download the latest patchset for Export/Import from Metalink. The current patchset as of this writing is patchset 2617359.
Once the minimum requirements are verified, your goal is to create a transport set. Transport sets contain the portal objects that you are planning to export to your destination portal environment. The steps below outline the basic process of creating a transport set for export. Please refer to the online documentation for the precise series of steps.
Before exporting/importing, please review Section 4 of the Oracle9iAS Portal 9.0.2 release notes, summarized here below:
By default, portal page URLs generated by Oracle9iAS Portal contain installation specific ID numbers that change when the object is exported. This causes broken links when pages are imported into a different site.
Here is an example of a URL generated for a page. If the page is imported on another site, this PAGEID will change.
http://my.portal.com/servlet/page?_pageid=47,49&_dad=portalr2&_schema=portal
If you are using URLs such as the above as manually-entered links, we recommend instead the use of Direct Access URLs or Page Link item types instead.
The same page has this direct access URL:
http://my.portal.com/pls/portal/url/PAGE/HRPAGEGROUP/HRHOME/HRBENEFITS
To find the direct access URL for a page, look at the page property sheet. A link to the property sheet can be displayed by adding a Property Sheet Smart Link item to the page.
Also, you can also use a Page Link item type to create a link to a page. The Page Link item type dynamically generates the correct link at runtime.
To ensure that links do not 'break' when pages are imported into a different site, always use Page Link item types or direct access URLs when creating links to pages.
For more information, refer to 'Direct Access URLs' and 'Page Links' in the Oracle9iAS Portal online help.
Page groups and their associated components may be moved from development to production via the export/import utilities described in this document. In addition to page groups as a whole, individual components within page groups such as subpages, categories, perspectives, page styles can be migrated individually to the import system, provided that the entire page group has been imported to the import system earlier.
Some considerations and best practices to keep in mind are the following:
In the current Oracle9iAS Portal 9.0.2.2 release, your import operation will fail with a MERGE_FAILED error if your web providers cannot be reached or cannot be registered successfully during import.
Before importing on your target system, all web providers referenced by your transport set must either exist already or be able to be registered successfully during the import on your target system.To ensure successful registration, ensure that your web providers meet the following conditions on your target system:
As with the export/import of portal content, the need to export users and groups depends primarily upon whether your Oracle9iAS Portal instances are sharing the same Oracle Internet Directory instance or not.
Review the following topics:
WWSEC_PERSON$.GUID)
Please refer to the Oracle Internet Directory documentation on how to migrate users and groups between Oracle Internet Directory servers.
At the end of the 4 step process, you should be able to edit the user or group profile and also see them in the imported objects access list. Keep in mind the order of the process outlined above. All the steps are required and must be carried out sequentially.
First of all you have to use the following steps to determine whether or not the specific group you want to synchronize is a local group:
By default, all local groups are created within the portal group install base. You can find the group install base by running the following commands in the portal schema from SQL*Plus:
set serveroutput on exec dbms_output.put_line(wwsec_oid.get_group_install_base)
If the tail of the group's distinguished name matches the value thus returned then the group is within the group install base else it is not. For instance, if the group install base is " cn=portal_groups,cn=groups,o=oracle,dc=com
" and the group that you want to synchronize has a DN " cn=Supervisors,cn=PORTAL_GROUPS,cn=Groups,o=oracle,dc=com
", then the tail is considered as matching and it is a local group. To confirm whether this is true or not you can try the following in the portal schema from SQL*Plus (please substitute the required group name for <enter_group_name_here
>)
select guid, dn from wwsec_group$ where name = upper('<enter_group_name_ here>');
If you see a row with the GUID and DN values then it is a local group else it is not.
Depending on whether or not it is a group within the portal group install base in Oracle Internet Directory you can use the following steps to synchronize the GUID of a specific group:
Use the following steps to get the GUID:
set serveroutput on exec dbms_output.put_line(wwsec_oid.get_group_info(p_group_name => '<enter_group_name_here>', p_check_local => false).guid)
This will display the GUID for the group.
Use the following steps to update the group entry in the portal schema
You have to know the Oracle Internet Directory host, port, the administrator's DN and password to run the following command. You also have to either know the Distinguished Name of the group or you should be able to determine by looking at a DN whether or not it pertains to the group that you are interested in. Use the following steps to get the GUID:
ldapsearch -h <enter_OID_host_name_here> -p <enter_OID_port_number_here> -D <enter_OID_admin_DN_here> -w <enter_OID_admin_password_here> -s sub -b "<enter_subscriber_DN_here>" "(&(objectclass=groupOfUniqueNames)(cn=<enter_group_name_here>))" orclguid
Example:
ldapsearch -h oid.oracle.com -p 389 -D cn=orcladmin -w welcome1 -s sub -b "o=oracle,dc=com" "(&(objectclass=groupOfUniqueNames)(cn=Supervisors))" orclguid
This will display a list of all groups under the specified subscriber whose name matches the specified group name. Every group will be displayed in two lines, the first line will have the DN of the group and the second line will have its GUID.
Get the DN and the GUID that you are interested in.
Pass the value of GUID to replace <enter_guid_here> and DN to replace <enter_DN_here> in the next command:
update wwsec_group$ set name = '(<enter_guid_here>)', guid = '<enter_ guid_here>' where dn = wwsec_oid.get_normalized_dn('<enter_DN_here>'); commit;
For example if the DN and GUID obtained from the previous step are
"cn=Supervisors,cn=OTHER_GROUPS,cn=Groups,o=oracle,dc=com
" and the GUID is "A729208AFBCA4C38E0340800208A8B00
" respectively then the above update query will become:
update wwsec_group$ set name = '(A729208AFBCA4C38E0340800208A8B00)', guid = 'A729208AFBCA4C38E0340800208A8B00' where dn = wwsec_oid.get_ normalized_dn('cn=Supervisors,cn=OTHER_ GROUPS,cn=Groups,o=oracle,dc=com'); commit;
These steps should allow you to synchronize a specific group in the portal schema. Repeat this process if there are multiple groups involved.
As mentioned earlier, be sure to review the latest information and FAQs on Oracle9iAS Portal Export/Import located in the Export/Import Migration and Upgrade folder at the following URL:
http://portalcenter.oracle.com
Please be sure to look for FAQs and documentation specific to Oracle9iAS Portal 9.0.2.2, as procedures and best practices for subsequent and prior releases of Oracle9iAS Portal do vary.
|
![]() Copyright © 2003 Oracle Corporation. All Rights Reserved. |
|