Considerations on WebCenter/ADF Performance

Performance for WebCenter/ADF is always a hot topic. For every application (ADF web apps, WebCenter Portal/Spaces apps, or others), you will be ended up to deal with it sooner or later. Sooner is of course better, it's recommended to be considered at the time the project is plotted out since you will need to consider your budget for hardware/software acquisitions. I have experienced with couples of clients that requested to tune performance after the application went to production which is still OK but not the ideal time, simple because there are so many restrictions dealing with performance tuning after it went on production. The performance no doubt is a broad topic. This article will try to include a checklist of areas you need to bear in mind for the matter of performance in the WebCenter/ADF world, but will not go into very detail on each section.

Performance is limited by many factors, such as hardware resource and the application architecture. The CPU type/speed, physical memory directly determines if there is any bottleneck to maintain the application performance at an expected level. The application architecture defines the interaction between applications, middleware components, databases and various business domains. It is a potential high-level constraint for the application performance if the application architecture is not laid out for best practice in performance, scalability and high availability. It is also important for business users or stock holders to understand user expectations. One way to set the expectations is to perform a capacity planning with assessment of system performance goals. Such information can be obtained to help understand the goals: anticipated number of concurrent users, amount of data and consistency, target CPU/memory usage, number and size of requests, network latency, etc.

Ideally, for a typical WebCenter/ADF application, consider the following setup in terms of performance, scalability and availability.

·                     Clustered Managed Servers

·                     Cache Servers (e.g: Web Cache Server)

·                     Hardware Load Balancer (and/or software load balancer)

Setting up the clustered environment will help performance by distributing loads over several managed servers. Besides, JVM garbage collection impact can be reduced and the response stability can be improved.

1. Caching 

Caching is another broad topic and can be addressed alone for another article. Basically caching can be implemented on various components on various layers. Caching can be implemented in the following areas:

·                     Client browser caching

·                     Web Cache Server caching

·                     Weblogic Server caching

·                     Database caching

Client browser caching and compression can be enabled to cache the compressed requested objects locally.  This way it saves the trips to fetch the cached objects from the server and performance can be greatly improved. To configure, Apache Http Server needs to be installed (Oracle Http Server is one type of Apache Server). Caching is enabled by defining the http header field "Cache-Control". Refer to here for details. The syntax could be:

Header set Cache-Control "cache-request-directive, cache-response-directive"

Apache uses mod_deflate module to compress. Refer to this link for details. Here is a list of MIME type that can be compressed:

·                     text/plain

·                     text/xml

·                     application/xhtml+xml

·                     text/css

·                     application/xml

·                     image/svg+xml

·                     application/rss+xml

·                     application/atom+xml

·                     application/x-javascript

·                     text/html

A file with extension ".conf" needs to be created for the caching and compression. The file needs to be put under $WebTier_Directory/instances/instance_name/config/OHS/ohs_name/moduleconf to be taken by OHS when the next time server starts.

Oracle Web Cache is the primary caching mechanism provided with Oracle Fusion Middleware. It improves the performance, scalability, and availability of Web sites that run on Oracle Fusion Middleware by storing frequently accessed URLs in memory. To use Web Cache, it needs to be installed and configured. You will need to configure the memory size for caching, define the caching rules, define the expiration policies, etc. Once the configuration is done, restart the web cache server and the caching activity can be monitored by the request statistics and popular requests. From there, you can also tell whether your caching rules are caching efficiently otherwise update or add new caching rules.

There are other caching available, like enable coherence on the weblogic server and database caching which will not be covered in this article. I would like to blog something on coherence in a later effort.

2. JVM Tuning 

JVM Tuning is another broad topic. Jrockit JVM is the default one for Fusion Middleware currently. It is the first JVM to adopt adaptive memory management system whose behavior is based on runtime feedback. The foremost advantage of automatic memory management is its contributions to the speed of the software development cycle. An additional advantage is that an adaptive memory manager may pick the appropriate garbage collection strategy for an application based on its current behavior, appropriately changing the number of garbage collection threads or fine turning other aspects of garbage collection strategies whenever needed. The question for which garbage collection algorithms is suitable for your WebCenter/ADF cannot be answered without investigation and analysis. A best way to analyze is to test your application with experiments. Try with different combination of GC policy, heap size, nursery size, and other parameter if applicable (eg: pause time target). Jrockit mission control provides a great graphic way to monitor the JVM performance. You could watch the JVM performances online or record the activities by flight recordings.

3. Application Tuning

Source codes with quality will be wrote with considerations of performance. There are so many places you can mess around with performances. Code refinement or code reviews by peers from time to time are always good practices. 

3.1 ADF BC/Faces Tuning

If you are working on an ADF project using BC as the model layer, there are a few declarative options to tune VO and AM pooling. ADF application should always be tested to ensure it's activation-safe by disabling AM pooling.

There are many tips on this sub-topic. I would refer to this Oracle document for details - Oracle ADF performance tuning.

3.2 WebCenter Portal/Spaces Application Tuning

There are numbers of factors that could impact the WebCenter Spaces/Portal performance inside application configurations. The following configuration files can be examined:

• adf-config.xml - Stores design time application-level settings, such as which discussions server or mail server the WebCenter Portal application is currently using.

• web.xml - Stores initialization parameters, custom tag library locations, and security settings.

• connections.xml - Stores connection details for WebCenter Portal services.

CSS/JavaScript can be heavily used in WebCenter portal/spaces applications. It's recommended to centralize those files to reduce the possibilities of duplicate usages. Since every page is based on a page template, the page template is a good start to be examined for any code refinement. Here is just an example list of items could be checked when examining a page.

a. Consolidate inline styling into one CSS file by converting all inline styles into class style.

b. Centralize CSS files if multiple CSS files exist

c. Consolidate individual JavaScript functions (from template, individual pages and custom task flows) into one centralized JavaScript file.

d. Identify and remove duplicate/redundant CSS, JS, ADF and HTML code (this is common in CSS especially).

e. Check the security permissions on the user visibility and rendered attributes for ADF component tags to make sure they are not making incorrect or duplicate calls.

f. Examine the following improvement points in the page source codes:

1) Component id attribute value length – if longer than 7 characters then change it less.

2) Client component attribute set to ‘true’ – This should be set to false most of the time unless there is a specific need for the component to be added in the DOM at the render time.

3) Immediate attribute – determines load behavior of the button to button (load immediately upon page load, or lazy ‘after’ page load).

4) Other property attributes – any other unnecessary or incorrectly configured attributes and ADF tags.

g. Search for render=”false” and visibility=”false” and remove if not needed.

h. Check all code – including the page definition for the template for any external references to resources and task flows that are not being used.

4. Others

4.1 OID/LDAP authenticator can be tuned and I would refer to this blog - Tuning Weblogic LDAP Authenticator Providers.

4.2 CDN is now supported in PS5. Check out this link for a How-to example.

Also, Logs can be helpful to determine performance issues.

To end, performance tuning is not one time job. Performance should be considered at the beginning of a project (before development) and carried on multiple times during development. After the development is done, stress test should be run at least once to make sure the application performance meets the business's expectations.