Continuous pursuit to optimize Weblogic portal performance

November 1, 2008 — 13 Comments

Weblogic needs a restart once in a while, but page cache wins the match!

At Componence we have been specializing in Weblogic Portal development for over 3 years now. The possibilities to integrate different systems / applications / services are really fenomenal, but the biggest pain for any portal platform is eventually the performance. Beside our own experiences within our Portletsuite development team, I heard the same from many developers / architects from all over the world; throughput can be 1-5 pages per second … (these numbers have been seen in single CPU to clustered environments up to 16 CPU’s).

Some related articles about performance issues with Weblogic Portal:

It’s about the portal size & amount of portlets used
Because of the structure of the portal and the used pageflow model the performance of the portal will drop substantially as the amount pages & portlets used increases. BEA even advises not to make portals bigger than 300 pages, because beyond that the portal will break at certain points. With the ease of use, accidently one of our customers made a portal by themselves with about 800 pages. I’m not sure if it’s Portletsuite, but the portal has been running quite stable for the last few months.

The big difference with regular web applications is the fact that a portal can run multiple applications at the same time on the same page. And each application can consist of multiple pages within it. And often each application can carry their own preferences set for it’s users. So compared with regular web front-end technologies Java Portals can create a lot more requests / threads, depending on the different portlet / applcations that is used on a page.

The Enterprise Java portal platforms have tried to tackle this by offering multi-threaded (simultaneous) portlet rendering. IBM and Oracle surely have it in their framework. But most open source portals do not offer it. This is probably the reason why Liferay portals can have issues with their performance. The Liferay standard portletset uses a lot of AJAX for asynchronous rendering to tackle these issues, but many customized portlets might not be. But I have heard that the open source Jetspeed portal does support this.

Portletsuite performance track gives hope
When we launched Portletsuite 1.0 three years ago for BEA Weblogic Portal 8.1 we had difficulties understanding the performance issues the portal framework brought along. I can remember medium portals had a throughput of 1-2 pages/second. Of course when compared with more regular web front-end frameworks this is a disaster. But it was just a fact and we had to deal with it.

After working together with BEA consultants, our PS 1.3 version released for Weblogic Portal 9.2 last year could handle a throughput of 7-10 pages/second. We had to change the architecture of our portlets to be better equipped to work better with the tree optimizer of the WLP framework and different caching possibilities.

Now with version 1.5 released in March this year, our performance again increased while we added may more new features to our standard Web 2.0 / WCM portlet set! With just the standard portlets in Portletsuite 1.5 a medium portal will generate a throughput of 17-20 pages/second.

Win the battle outside of the portal!
While most developers, IT managers, architects are focussing on how to improve the performance of the portal, the battle can be won elsewhere. Fixing internal portal performance issues will only have 10-20% effect on the user experience. The following 2 areas related to the webserver & browser cache will give greater results for the users:

  • Decrease unnecessary browser requests & download
    The best wins are gained in the browser! Nowadays pages are typically > 500KB big and require >50 HTTP requests to build up their site. The browser takes a lot of time to retrieve these resources and to build up the page, easily taking 5-10 seconds. By making sure that each resource has an expiry date in it’s headers, this way many re-occuring resources do not need to be downloaded. This will easily decrease the amount of HTTP requests to 2-5 when visitors come back to the portal. The result will be that the browser will need easily 50% less time to build up the page. This fix will not have a substantial effect on the throughput.
  • Make entry pages cacheable
    In customer facing portals, many entry pages will have content. Content is not always static, but can easily handle a delay of 5 minutes. If you can cache up to 10 pages that are responsible for 20-30% of the pageviews, then chances are that the throughput can easily be increased with 10 times. And the average response time will drop dramatically. This is what we have proven in a portal that we have built. After turning on the page cache, only for anonymous users, the reports shows that the average response time dropped easily below 1 second.

Page cache for the homepage was good enough to stabilize this portal

Portal page caching with Portletsuite
The portal page cache solution, that is available in Portletsuite 1.6, was merged in this portal that was based on Portletsuite 1.4. The portal page caching solution enables portal administrators to easily select / deselect the pages that need to be cached in the virtual memory. With this solution I’m quite sure many Weblogic Portal clients can easily increase their ROI, as Enterprise portal investments are usually huge. I’m quite happy that in Portletsuiet 1.7 we will also enable caching for users with entitlements and preferences.

And just to think that many colleagues and clients were scrutinizing this solution of Abhay, one of our most talented colleagues in Jaipur, almost causing him to stop this line of development … Thank you Abhay!

Advertisements

13 responses to Continuous pursuit to optimize Weblogic portal performance

  1. 

    Nice post Ha! Very informative… Big props!
    It seems there’s a lot you can teach me 😉

  2. 

    Haha, well, I just learn a lot from my colleagues that really make things work. This blog is just dedicated to the hard work that many of my colleagues have done to improve the performance. Just some names: Yaroslav Lazor, Tycho Luyben, Erik Hofstra, Aleksandr Petrenko, Andrew Shwed.

    I’m just the type of manager that managers should be more, always trying to really listen and understand the ideas of my crew 😉

  3. 

    Good information. Portals tend to be complicated web pages with many artifacts. As you point out, a lot of the performance has to do with the number of HTTP requests for static files.

    Using a tool like YSlow to find easy ways to optimize the HTTP traffic can often dramatically improve perf of a WLP site.

    • 

      Hi Peter,

      I was wondering if you’re involved with the new WebCenter framework / services productline by Oracle. Do you know it the performance of the original Oracle technology (ADF, taskflows) is better or worse than Weblogic Portal?

      I’d greatly appreciate your comments.

      Ha

  4. 

    Hi Peter,

    Yep, our developers have YSlow as a mandatory tool in their Firefox browser. It’s a great tool, any web developer should use it to optimize the performance of the web application.

  5. 

    It seems that our solution can work for different application servers. We’ll be checking this out for a Tomcat server soon. Hopefully we can help another client.

  6. 

    Добавил в закладки. Теперь буду почаще читать!

  7. 

    Hi, I wanted to know more details about ‘each resource has an expiry date in it’s headers’ How do you manage this using WLP servlets like ShowProperty or others.. I do not see the ‘Last-Modified’ header is response coming for resources managed by WLP CMS
    If you can throw some light, it will be really helpful for me…
    Thanks in advance

    • 

      Hi Dhiraj,

      I’ll ask one of my colleagues to provide an answer.

      Bye,

      Ha

      • 

        I have been try to get more details around this problem and it seem now I know full problem statement.
        The precise problem definition is –
        1. Missing ‘Last-Modified’ HTTP header from response. This header needs to be managed by component that serves the resource from WLP repository
        2. Missing validation by WLP when browser sends ‘If-Last-Modified-From’ header.
        Will let you know if I make any further progress…might help readers

  8. 

    That was remarkable post. I like to read articles that are edifying for they enriched my mind with different knowledge that makes me a better person. These articles especially about recent events, technologies, news, tips and technical skills are the topics that I adore. Keep it up and more power to your website. I look forward for your next article.Thanks Jennifer Liferay Portal Development

  9. 

    Each new age brought the criminal element forward with it.
    In addition, many of the words used started to take on slightly different meanings, depending on the context in which
    they are used. It’s probably some mix of the two, so I have to give him props for not going too far in either direction.

Trackbacks and Pingbacks:

  1. It’s good to be back in Jaipur – improvements, new ideas, nice people and good vegetarian food « Ha’s Blog - November 24, 2011

    […] exiting meeting was the kickoff session for a new product, a caching layer that will allow portals to perform much faster than it is now. This time it was not just a technical talk, but the complete picture was discussed starting from […]

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s