OBIEE 11g User Interface (UI) Performance Is Extremely Slow With Internet Explorer 8

Bienvenue… Mes amis ..@ Welcome back …

…./// was struggling for last couple of weeks with OBIEE 11g (11.1.1.5) and IE 8 . The experience was awesome !! pathetic …  it is extremely slow starting from login page and browsing across reports/changing the reports views/layouts and while play with overall application ad-hoc basis.

The situation has been observed not for desktop/laptop standalone application users(at-least I don’t have issue in my personal desktop)  but for VPN or WAN users over the network 😦 😦

Initial assumption was that it is due to OBIEE 11g with its lot of junkies (animations ,flash plugin and special chart rendering engine etc..) .I thought it could be a database problem as for my case database was also not pretty strong. So overall performance issue could be for new OBIEE 11g. It was so irritating to develop a reports there which can pretty easily frustrating a developers . Even the console and EM window and other navigation options was pretty slow.

Later while install Mozilla Firefox we can see a significant performance improvement and the application is running cool like a charm !! So the main culprit for entire problem is the favorite “IE 8” browser !!  (Nowadays I didn’t even open my IE until a very specific needs) . So I switch to different browser at-least to make sure I didn’t spend my 20 minutes of time just for build a reports….huh… A shy of relief after spending my last painful weeks …

Now what is the reason behind IE 8 slowness while interacting via web server to OBIEE engine . There is no fighting game between two killer giants “Microsoft” and “Oracle”  , I believe… 🙂

As per Oracle “IE 8 generates many HTTP 304 return calls and this caused the 11g(11.1.1.3 and later) UI slower when compared to the Mozilla FireFox browser.”

Hmmm … so HTTP 304 error caused when the poor developer doesn’t respect the HTTP protocols completely … not bad … 🙂

So what is this HTTP 304 …let’s have a look ..

HTTP 304 doesn’t really indicate an error, but rather indicates that the resource for the requested URL has not changed since last accessed or cached. The 304 status code should only be returned if allowed by the client . The client specifies this in the HTTP data stream sent to the Web server e.g. via If_Modified_Since headers in the request.

Systems that cache or index Web resources (such as search engines) often use the 304 response to determine if the information they previously gathered for a particular URL is now out-of-date.

+++++++++++++++

§  304 errors in the HTTP cycle

Any client (e.g. your Web browser or our CheckUpDown robot) goes through the following cycle when it communicates with the Web server:

• Obtain an IP address from the IP name of the site (the site URL without the leading ‘http://’). This lookup (conversion of IP name to IP address) is provided by domain name servers (DNSs).
• Open an IP socket connection to that IP address.
• Write an HTTP data stream through that socket.
• Receive an HTTP data stream back from the Web server in response. This data stream contains status codes whose values are determined by the HTTP protocol. Parse this data stream for status codes and other useful information.

This error occurs in the final step above when the client receives an HTTP status code that it recognises as ‘304’.

§  Fixing HTTP 304 errors – General

You should never see this error in your Web browser. It should simply present the Web page from its cache – because it believes the page has not changed since it was last cached. If your client is not a Web browser, then it should equally be able to present the page from a cache. If unable to do so, it is not using the If_Modified_Since or related headers correctly.

§  Fixing HTTP 304 errors

You should never see this error at all for the CheckUpDown service. It indicates defective programming by us or the developers of the Web server software. Either we or they are not respecting HTTP protocols completely.

The 304 status code should only be returned if we allow it in the HTTP data stream we send to the Web server. Because we keep no records of the actual content of your URL Web page, we specifically disallow the 304 response in the HTTP data stream we send.

So if the Web server implements the HTTP protocol properly, it should never send an 304 status code back to us. This response is not what we expect, so we actively report it as an error even though it does not necessarily mean that the Web site is down.

Please contact us directly (email preferred) whenever you encounter 304 errors. Only we can resolve them for you. Unfortunately this may take some time, because we have to analyse the underlying HTTP data streams and may have to liaise with your ISP and the vendor of the Web server software to agree the exact source of the error.

++++++++++++++++

So enough fade up with HTTP 304… lets see how Oracle proposed to resolve the problem using “HTTP compression and caching” technique.

Why use Web Server Compression / Caching for OBIEE?

o       Bandwidth Savings: Enabling HTTP compression can have a dramatic improvement on the latency of responses. By compressing static files and dynamic application responses, it will significantly reduce the remote (high latency) user response time.

o       Improves request/response latency: Caching makes it possible to suppress the payload of the HTTP reply using the 304 status code.  Minimizing round trips over the Web to re-validate cached items can make a huge difference in browser page load times.

This screen shot depicts the flow and where the compression and decompression occurs.

The Solution:

1.      To implement HTTP compression / caching, install and configure Oracle HTTP Server (OHS) 11.1.1.x for the bi_serverN Managed Servers (refer to “OBIEE Enterprise Deployment Guide for Oracle Business Intelligence” document for details).

2.      On the OHS machine, open the file HTTP Server configuration file (httpd.conf) for editing.

This file is located in the OHS installation directory.
For example: ORACLE_HOME/Oracle_WT1/instances/instance1/config/OHS/ohs1

3.      In httpd.conf file, verify that the following directives are included and not commented out:

LoadModule expires_module “${ORACLE_HOME}/ohs/modules/mod_expires.so

LoadModule deflate_module “${ORACLE_HOME}/ohs/modules/mod_deflate.so

4.      Add the following lines in httpd.conf file below the directive LoadModule section and restart the OHS:

Note: For the Windows platform, you will need to enclose any paths in double quotes (“)

For example:

Alias /analytics “/ORACLE_HOME/bifoundation/web/app”

<Directory “/ORACLE_HOME/bifoundation/web/app”>

Alias /analytics ORACLE_HOME/bifoundation/web/app

#Pls replace the ORACLE_HOME with your actual BI ORACLE_HOME path
bifoundation/web/app>
#We don’t generate proper cross server ETags so disable them
FileETag none
SetOutputFilter DEFLATE
# Don’t compress images
SetEnvIfNoCase Request_URI \.(?:gif|jpe?g|png)$ no-gzip dont-vary
<FilesMatch “\.(gif|jpeg|png|js|x-javascript|javascript|css)$”>
#Enable future expiry of static files
ExpiresActive on
ExpiresDefault “access plus 1 week”
#1 week, this will stops the HTTP304 calls i.e. generated by IE 8
Header set Cache-Control “max-age=604800”
</FilesMatch>
DirectoryIndex default.jsp
</Directory>

#Restrict access to WEB-INF
<Location /analytics/WEB-INF>
Order Allow,Deny
Deny from all
</Location>

Note: Make sure you replace above placeholder “ORACLE_HOME” to your correct path for BI ORACLE_HOME. For example: my BI Oracle Home path is /Oracle/BIEE11g/Oracle_BI1/bifoundation/web/app

 Important Notes:

• Above caching rules restricted to static files found inside the /analytics directory(/web/app).
• This approach is safer instead of setting static file caching globally.
• In some customer environments you may not get 100% performance gains in IE 8.0 browser. So in that case you need to extend caching rules to other directories with static files content.
• If OHS is installed on separate dedicated machine, make sure static files in your BI ORACLE_HOME (../Oracle_BI1/bifoundation/web/app) is accessible to the OHS instance.

Summary

The following screen shot summarizes the before and after results and improvements in response times(in IE7 and IE8) after enabling compression and caching: 

So now get the enthusiasm back and play with OBIEE 11g … 😀

But as per my observation till now, OBIEE 11g is still pretty slow specially in developers mode when you are editing some views in compound layouts,playing with measures and switch across columns across different sections ! It is still not best bet in regard of performance and response time … !

The portion of the above information of the has been actually except  from Oracle Support ID (1312299.1) .

In the upcoming thread I will explain a loads of  OBIEE 11g related bug/issues and unpredictable behavior and couple of non-working and missing treasures …..

Stay tuned until then …..

Yours (:))> DxP