Wednesday, June 22, 2011

Disabling Content Compression in WebCenter Spaces

By default, and for performance/optimization, WebCenter Spaces runs in the browser with the page markup generation compression set to be ON. 

However, there are cases when you are developing a customized skin (CSS) for Spaces, that you need to "see" the actual component's style class selector name (af_panelGroupLayout), not the compressed version (i.e. xyz).  To disable the compression is an easy step.  Bascially, you will need to add a context-param to Spaces web.xml:


What's not so intuative is how this is achieved in Spaces.  The best way to do this is through the extension workspace, DesignWebCenterSpaces.jws.  You can get more information on "extending" Space, and also the download link to the workspace here.  Once you have downloaded (and configured) the DesignWebCenterSpaces workspace, you can then follow the next steps.

Double-click the WebCenterSpacesExtensionLibrary project inside the workspace.  This will open the Project Properties dialog. In the left pane, select the Project Source Paths.  In the "Included" tab section, click on the "Add..." button.  From within the "Add Include Filters"dialog, navigate to and select the web.xml file from within the WebCenterSpacesExtensionLibrary/public_html/WEB-INF directory. 

Click OK to dismiss the dialog.  This will add the web.xml to the project.

Next, in the left pane, click on "Deployment".  In the right pane, select the custom_webcenter_spaces_war (WAR File) deployment profile, and click the "Edit..." button.  This will open the Edit WAR Deployment Profile Properties dialog.  In the left pane, open the "File Groups", "Web Files" section, and select "Filters".  In the right pane, check the web.xml file.

Click OK, to save and dismiss the dialog. Next click OK to save and dismiss the Project Properties dialog.  In the Application Navigator, expand the WebCenterSpacesExtensionLibrary\public_html\WEB-INF folder.  Notice that the web.xml has been added.  Double-click on this file to open it in the file editor.  Remove the <filter>, and <filter-mapping> tags, as these tags are not needed.  Next add the tags that will enable the disabling of the content compression:


Save the file.  The next step is to regenerate the WAR file for deployment.  (Note: by default (OOTB), there is already a version of this war, which has been deployed to the Spaces server.  The deployment process will created a "versioned" war.  More on this later ...)  Locate the build.xml file, which is located within the WebCenterExtensionLibrary project.  Right-click on the build.xml, and from the context menu, select "clean stage" from the Run ANT target menu options.

This will create the new "extend.spaces.webapp.war" file, which will update the already deployed version in Spaces.  Before deployment, you can check to see if the web.xml has been added to the war by looking into the "exploded" directory. For example:

You will see a <servlet> tag has been added along with the content compression based tag, but this is OK.  Once you have confirmed that the web.xml has been added.  You are ready to deploy the new war to the WebLogic managed instance. Locate the build.xml file again.  Next right-click on the file, and from the context menu, select "deploy-shared-lib" from the Run ANT target menu options.

The ANT task will run and deploy the new version of this war.  After a successfull execution, you can view the new deployment in the WebLogic console.  The newest version, signified by the highest version number, will be the library that gets used by WebLogic.

After the deployment has been verified, you will need to RESTART the Spaces managed instance.  Once this is done, open up Spaces and for example, in Firebug you will notice that the style classes are displaying the real names. 

 As you can see, this option can really help speed up the development of a CSS, and ensure that you are using the right style class.

Wednesday, June 15, 2011

Improving WebCenter Performance – Part 2

If you read George’s previous post you can also improve the client side performance, this is useful if you are running a demonstration, workshop or have a controlled IT environment where you have mandate to configure the client browser environment.
This post will look at how we can improve the client side experience of the performance and also limit the computation time for certain common operations.

Login process
The login process takes in general longer time than the subsequent operations, there is several reasons for this one is the caching which George already addressed. Secondly if you have large identity store or limited response times from the directory servers you can implement caching so the ldap bind, authentication and user information retrieval impact can be reduced.

Add following lines to jps-config.xml:

   1: <serviceInstance name="idstore.ldap" provider="idstore.ldap.provider">
   2:     <property name="idstore.config.provider" value=""/>
   3:     <property name="CONNECTION_POOL_CLASS" value=""/>
   4:     <extendedProperty>
   5:       <name>user.object.classes</name>
   6:          <values>
   7:          <value>top</value>
   8:          <value>person</value>
   9:          <value>inetorgperson</value>
  10:          <value>organizationalperson</value>
  11:          <value>orcluser</value>
  12:          <value>orcluserv2</value>
  13:          <value>ctCalUser</value>
  14:        </values>
  15:   </extendedProperty>
  16: </serviceInstance>

The jps-config.xml can be found in the domain configuration where the affected managed server is running

For more information see:

Browser tuning
Many organizations are using Internet Explorer in various version, currently when Internet Explorer is installed it comes with following download concurrency support:
Version 7: Two simultaneous download threads
Version 8: Six simultaneous download threads
Considering Georges previous blog about the near 100 downloads for some page requests when caching is not present, to tune the browser can improve the perception of the performance for the user. Microsoft has released two self fixing steps that can be taken to increase the concurrency to 10.

If you want to implement the steps manually or automatic please refer to the link below, remember to use the browser version you want to target so you get the right fix.

For more information see:
If you click the “Fix it” link then it will download the registry fix and install it for you, alternatively you can use the manual procedure.

Wednesday, June 1, 2011

Improving WebCenter Performance – Part 1 (IIS Addendum)

If you read my previous post you might be wondering if you can achieve a similar performance with a different Web Server such as Microsoft Information Server. In this article I’ll describe the steps you need to follow to have IIS not only applying content compression, but also rewriting the expiration data in the HTTP header.


1. Open the Internet Information Services Manager, right-click on the Default Web Site option and select Properties.


The window below should show up. Check the “Expire after” option and set it to 1,193 Hour(s). It will change the HTTP header Cache-control parameter from Expire to max-age in all local static resources, which solves the Internet Explorer caching issue.


Click on the MIME Types button and add the following ones:


Select the ISAPI Filters tab and check where the WebLogic ISAPI plug-in (wlFilter) is installed. The plug-in allows a smooth integration of WebLogic's HTTP functionality into Microsoft IIS.


Under the iisforward.dll’s directory you should find iisproxy.ini. Open the ini file and add the FileCaching=ON property as shown below. It will add another level of buffer to IIS and force it to add Content-Length property to the HTTP Header.

WebLogicHost=<WebCenter / Load Balancer host> 
WebLogicPort=<WebCenter / Load Balancer port> 

5. Make sure content compression is still setup. Right-click on Web Sites and choose properties.


Select the Service tab. The “Compress static files” option must be checked.


Don’t forget to restart IIS after the changes.

Improving WebCenter Performance – Part 1

Tuning is quite a long and complex subject to be discussed in a single article. This first post will cover 2 basic strategies to make your Oracle WebCenter installation faster by tweaking the browser caching and adding content compression. By the end of this article your WebCenter pages should be rendering in less than 2 seconds – obviously depending on your environment – and with fewer requests.

Browser Caching

Your browser has a folder in which certain items that have been downloaded are stored for future access. Images, stylesheets, javascripts, and even entire web pages are examples of cached items. When accessing a website, your browser will check its cache folder first to see if it already has those images and, if so, it won't take the time to download them again.
There are two main reasons that web caches are used:
To reduce latency — Because the request is satisfied from the cache instead of the web server itself, it takes less time for the representation to render in the browser.
To reduce network traffic — Since there are less items to be downloaded from a web site, it reduces the amount of bandwidth used by a client.
Like in any other application, WebCenter Portal have static resources that need to be cached by the browser in order to reduce subsequent download access. The trick here is to setup OHS to rewrite the HTTP header of some specific virtual paths related to static resources in WebCenter.
We will use max-age instead of Expire. The max-age directive specifies the maximum amount of time that a representation – or file - will be considered fresh. From my perspective, the big advantage of this directive is that it’s relative to the time of the request, rather than absolute. max-age also seems to behave better with IE in general. I haven’t checked that in IE 9 so far. For this exercise, we’ve setup max-age to 2592000 seconds (30 days).

Header unset Last-Modified
Header unset Expires
Header set Cache-Control "max-age=2592000, public"
Header set Surrogate-Control "max-age=2592000"

Content Compression

To do content compression in OHS you need to configure mod_deflate. It should already be installed in your OHS under $MIDDLEWARE_HOME/Oracle_WT1/ohs/modules/ But it might not be loaded.

LoadModule deflate_module        "${ORACLE_HOME}/ohs/modules/"

With mod_deflate, you can compress HTML, text or XML files to approx. 20 - 30% of their original sizes, thus saving you server traffic. However, compressing files causes a slightly higher load on the server, but again, clients' connection times to your server decrease a lot.

mod_deflate requires you to specify which type files are going to be compressed.

AddOutputFilterByType DEFLATE text/plain
AddOutputFilterByType DEFLATE text/xml
AddOutputFilterByType DEFLATE application/xhtml+xml
AddOutputFilterByType DEFLATE text/css
AddOutputFilterByType DEFLATE application/xml
AddOutputFilterByType DEFLATE image/svg+xml
AddOutputFilterByType DEFLATE application/rss+xml
AddOutputFilterByType DEFLATE application/atom_xml
AddOutputFilterByType DEFLATE application/x-javascript
AddOutputFilterByType DEFLATE text/html

Images are supposed to be in a compressed format, and therefore are bypassed by mod_deflate.
SetOutputFilter DEFLATE
SetEnvIfNoCase Request_URI \.(?:gif|jpe?g|png)$ no-gzip dont-vary

Quick Setup

To have all those changes applied to your environment, please download webcenter.conf and replace the variables listed below accordingly.
  • [wc_spaces host]
  • [wc_spaces port]
  • [wc_services host]
  • [wc_services port]
  • [ses host]
  • [ses host]
If you already have portlets being consumed by your application, don’t forget to add the proper mod_wl entries.

#Insert your portlet mapping here
<Location /[portlet path]>
SetHandler weblogic-handler
WeblogicHost [wc_portlet host]
WeblogicPort [wc_portlet port]

And if you have already separate the static assets from your application into a different directory, you might want to set the same configuration:

Alias /[virtual path for static files] [physical path for static files]
<Location /[virtual path for static files]/>
Header unset Last-Modified
Header unset Expires
Header set Cache-Control "max-age=2592000, public"
Header set Surrogate-Control "max-age=2592000"

After doing the proper setup you can drop the webcenter.conf file into $MIDDLEWARE_HOME/Oracle_WT1/instances/instance1/config/OHS/ohs1/moduleconf. You MUST restart OHS for the changes to take effect.


Now let’s access WebCenter to see how fast it is. The first access any WebCenter Spaces page should be faster since we’re using content compression, but it should still bring lots of resources such as js files, images, css, etc.
1st Access
Activities page renders in approximately 7.5 secs with 91 requests.
2dn Access
A subsequent access to the same page takes less than half a second and only requires a single request. All other static assets are cached by the browser and don’t need to be downloaded again.
Any other request to pages that haven’t been accessed before should take less requests to render, since most of the WebCenter resources have been downloaded previously.
Spaces page takes 1.1 seconds and 7 requests to render. Blazing fast, my friends!

Debugging Taskflows in WebCenter Spaces

For those who do not know, Oracle WebCenter Spaces is a ready-to-use application that delivers dynamic business communities and pulls together the capabilities of all the WebCenter Services. Oracle WebCenter Services provides a comprehensive set of standards-based components that enrich existing portals and Web sites with the industry's most complete and open set of Enterprise 2.0 capabilities. These Social Computing Services include wikis, blogs, online awareness and communications, content collaboration and social networks. Oracle WebCenter Services works with all Oracle portal offerings, enabling organizations to enhance their existing enterprise portals and Web sites, and empowering users with Enterprise 2.0 services that work with their existing information systems.

WebCenter Spaces can be customized using browser-based tools and also using JDeveloper. For example, you may want to deploy additional shared libraries that include custom code or some additional task flows. Or, you might want to edit/create WebCenter Spaces resources, such as skins, page templates, and navigations, in JDeveloper.  When developing the custom task flows in JDeveloper, there are many times that you will need to test/debug the code after the code has been deployed to a running instance of Spaces.  In this post I will describe how to accomplish this process.

Configuring the Spaces Managed Server Instance

The first step towards enabling debugging is to be able to start the WebLogic managed server, which is hosted Spaces, in debug mode.  One way of setting this up is to modify the (linux)  that will start Spaces.  This script is located in the <oracleHome>/user_projects/domains/<wc_domain>/bin directory. However, since this script is used to start all of the WebCenter hosted services (UCM, Collaboration, .etc), this would mean that these instances would be started in debug mode as well.  Yes, this would be OK, but unneccesary for what I want to do.  So what I do is to make a copy of this script (name the file something like and then modify this version of the script.

In the new file locate the section that declares the JAVA_OPTIONS. 
Modify the file and add the debug java options: -Xdebug -Xnoagent -Xrunjdwp:transport=dt_socket,address=4000,server=y,suspend=n to the JAVA_OPTIONS.  For example, in my file I added this option in front of the existing option already there:

JAVA_OPTIONS="-Xdebug -Xnoagent -Xrunjdwp:transport=dt_socket,address=4000,server=y,suspend=n"/home/oracle/Middleware/wlserver_10.3/server/lib/cacerts" ${JAVA_OPTIONS}"

Once this is done you will be able to use this script to start Spaces in debug mode. To check to see if the option has been enabled you will see the reference to the debug mode: Listening for transport dt_socket at address: 4000 in the Spaces terminal window.

Configuring JDeveloper

The next step is to enable the remote debugging feature for your project in JDeveloper.  To do this, go to your project's properties. Select the Run/Debug/Profile section, and click the Edit button for the "default" setting.  This will bring up a dialog where you can check the Remote Debugging option.

After this step you can then proceed to set breakpoints in your source, and then "Attach" to the running debug WLS instance. To attach, simply right click on the project (in the JDeveloper application navigator) and from the context menu, select "Start Remote Debugging".

Here's a screen shot of a JDeveloper debug session, debugging the WebCenter Page Service native API code, which I had blogged about in a previous post.

As you can see, being able to debug you Spaces based code in a running Spaces instance can be invaluable for tracking down those nasty bugs, and is very easy to set up.