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.
With version 1.5 released in March last year, our performance again increased while we added many 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 .
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!