Vivek Agarwal’s Portal/Java Blog

An IBM Gold Consultant’s weblog about IBM, Lotus, WebSphere, J2EE, IT Processes, and other IT technologies

WebSphere Portal 5.1 Performance Trap

Posted by Vivek Agarwal on October 26, 2005


Introduction

I have been working on a client project to upgrade their Intranet from WebSphere Portal v4.2 to v5.1. Not only has this project involved the normal challenges of upgrading WebSphere Portal (went through that hell twice from v2.1 to v4.1, and then from v4.1 to v4.2), but we have the added complexity of working in a dual master site set up where the two WebSphere Portal sites are expected to stay in sync through data replication. Over the course of this project, we have encountered many challenges and issues and I will try to cover some of them through my blog.

Now onto the substance of an issue that we encountered that I believe is a huge performance trap with WebSphere Portal v5.1 …

WebSphere Portal v5.1 Performance Trap

As we migrated our custom functionality (themes, skins, portlets, and content) to v5.1, we noticed that the performance was less than spectacular. We tried switching to the standard WPS themes and skins, but the problems remained. I had noticed that our wps*.log files had many occurrences of the following exception –

2005.09.08 14:23:03.811 W com.ibm.wps.engine.Servlet doGet()
class com.ibm.wps.state.nls.inputmediators.exceptions.NlsCannotInterpretStateException: Unspecified message ()

However, the Portal seemed to be functioning alright and I did not think much of this exception – seemed fairly innocuous. We had sent log files that had this exception to IBM support in relation to another issue that I will cover in another blog item, and they did not inform us that this was anything significant (even though that issue was also related in some senses to this exception).

We started monitoring our application logs and noticed that as we navigated around the Portal site, the home page (the page the user is directed to after Portal login) portlets were getting executed multiple times – i.e. when we visited page “X”, the Portal was executing the portlets on page “X” and also the portlets on page “Y” (where “Y” was the user’s home page). And in fact, was executing the portlets on page “Y” multiple times! Obviously a recipe for performance issues. Then we tracked this down to some of our Portal pages that had instances of the JSP portlet – we have many category overview pages that use a JSP to give an overview of the functionality under that tab. Then it was a battle to determine what in the JSP portlet could cause the issue – finally determined that anytime WPS has trouble decoding a URL, it ends up executing the home page (and hence the home page portlets). Some of our overview jsps have bad image/css references and each bad reference ends up executing the home page! In some cases, the home page portlets execute as many as 6/7 times for a single page load of a Portal page containing basically a static text jsp. On one of our custom themes, we had a favorite icon reference that pointed to an image in the theme – accidentally, somebody deleted that image and urlFindInTheme could not find the image, and so we had a blank href for the favorite icon. That resulted in executing the home page portlets as well!

All in all, if you have a single bad link in your portal page, then you will end up executing the user’s home page. The user will be directed to the correct page that the user is trying to navigate to, but this will put extra load on the Portal Server and depending on the browser will significantly impact end-user performance (if the browser waits for all items to load before rendering the page). This is a huge performance trap that is not documented anywhere in the Portal documentation. We have found this the hard way and are trying to get IBM to acknowledge that this is not acceptable behavior. However, we have not had luck so far. IBM Support’s response has been that it is the developer’s responsibility to fix all URL references. I agree that URL references should be correct, but it is unacceptable for the Portal to behave this way. Think about it – you have content authors on your Intranet and they inadvertently introduce a bad link in the content and you will encounter this issue.

However, until IBM changes the behavior you should be forewarned that if you see the NlsCannotInterpretStateException in your wps log files, DO NOT ignore it. It is far from innocuous.

Advertisements

11 Responses to “WebSphere Portal 5.1 Performance Trap”

  1. Rick Fryar said

    I work for a Major manufacture that uses Portal. We are currently forcing them to fix this problem, however not due to performance reasons but for external search reasons.

    When you remove a portal page the old URL will still function (And take the user to the “welcome” page). This is not advantageous to external search as it will not expire your content. So hopefully this fix when it comes will resolve your issues as well.

    Good luck, portal has many large issues that we have worked through in the last 3 years of working with it.

    Rick

  2. Vivek Agarwal said

    Thanks for your comment regarding WebSphere Portal?s performance trap of executing the home page (and its portlets) whenever it encounters essentially a 404 error. We are still fighting the IBM support team to get this fixed or at least to get a patch such that they do not do this on a image/css/js request. If you get this patch, I sure would appreciate you letting me know.

    Yup, while working with WPS you are never lacking a challenge!

  3. fida said

    Any updates on NlsCannotInterpretStateException..
    did you have any workarounds or solution.
    TIA

  4. Vivek Agarwal said

    Check out my blog entry titled “Update on WebSphere Portal Malformed URLs” (http://jroller.com/page/vagarwal?entry=update_on_websphere_portal_malformed) for an update on this issue.

  5. fida said

    Thanks for the response Vivek.

    I have seen that blog, IBM says that we need to migrate to 5.1.0.2 to apply the fix which prints out malformed URL, I am not sure if you had any simpler solution.

    Also, another thing I have noticed is that we get two similar exceptions…

    For instance the first one is the one what you have mentioned in your blogs:-

    2005.12.06 13:56:45.987 W com.ibm.wps.engine.Servlet doGet()
    class com.ibm.wps.state.nls.inputmediators.exceptions.NlsCannotInterpretStateException: Unspecified message ()

    the second one is:-

    2005.12.06 13:56:50.224 W com.ibm.wps.engine.Servlet doGet()
    class com.ibm.wps.state.nls.exceptions.NlsCannotInterpretCodecException: EJPEI0073E:

    I was just wondering if you encountered the other one too? and wanted to know if you have any suggestions for this one.

    Appreciate your help.
    Thanks

  6. Ekraam said

    Hi,

    I was getting the same problem when trying to access a captcha servlet on wps5.1 which worked absolutley fine on 5.0.The exception looked like
    W com.ibm.wps.engine.Servlet doGet() Invalid URL ‘http://www.ABC.com/1/2/1/PA_1_0_IL/ABCCAPTCHAServlet’
    [10/31/06 14:19:12:254 EST] 1bdd4784 PortalServer W com.ibm.wps.engine.Servlet doGet() class com.ibm.wps.state.nls.exceptions.NlsCannotInterpretCodecException: EJPEI0073E: The input mediator class com.ibm.wps.state.inputmediators.WPInputMediator@1709442945 could not interpret codec 1 for request com.ibm.wps.engine.PortalRequestWrapper@3f97c7fa.

    Looking at the URL carefully indicates that url has been rewrtten as I was trying to hit ‘http://www.ABC.com/1/PA_1_0_IL/ABCCAPTCHAServlet’.

    So the explanation is something like “URL is being rewritten by the WAS HTTP plugin as it fails to pass a filter, so they add /1/2 to the front and then that’s passed
    to WPS, and that understands the /1/2, but that mess ups the next bit and hence results in this error”.
    To resolve it, webserver re-write rules(security.conf) for SSL and None SSL redirects) should be modified to allow certain requests through for displaying resources in the some folder or allowing requests images ,servlets, audio etc. A typical rewrute string would look like “RewriteCond %{REQUEST_URI} !^/1/P.*(gif|jpg|css|js|pdf|Servlet|swf)”.

    This resolved my issue and i am able access my servlets now.

    You might also need to add the following statement in webserver plugin config (specially for url rewriting based session handling)

  7. Vaidee said

    Hi Vivek,

    We are trying to integrate WPS 6.0 with TAM and WebSEAL. Could you help us with detailed steps or direct us to some location that details one? Thanks in advance.

    Vaidee

  8. […] that I would put out an update on the WebSphere Portal performance issue that I covered in a previous blog entry. Basically we have been following up with IBM support (and a couple of senior IBM contacts that I […]

  9. Varsha said

    We are getting this error in our logs too. Can you tell me if this can be one of the reasons for deployment failure?

  10. Bhargav said

    Thanks for the blog. I have been working on portals for the past few months. Fortunately or unfortunately i had the luck of working on the ‘home page’ of our application. Our application too encountered similar problems of ‘my’ home page’s doView() methods getting called many times unnecessarily and i had a tough time convincing my team that it wasn’t one of my mistakes. Finally i could solve the images/css problem. Your blog helped in resolving my problems. Thanks.

  11. Vivek Agarwal said

    Hey Bhargav,

    Thanks for your comment and I am glad that it helped you out! This is a particularly sore point with me on WebSphere Portal – way too easy to have this issue kill performance on portal and way too painful to resolve it. 😦

    Unfortunately the behavior is the same on v6.0 as well!

    -Vivek.

Sorry, the comment form is closed at this time.

 
%d bloggers like this: