Poor performance in a portal production environment will quickly become your number one complaint from your employees, partners and customers.  Given an option, your user community will look elsewhere and not come back.  Performance testing and load testing are often left to the last minute or skipped all together.  If 2 weeks before launch you hear “performance is a little slow, maybe we should run a test,” you’re project is in serious trouble.  You always need to give yourself ample time in a project to introduce realistic expected user loads and monitor the performance during the tests.

Why should I load test?  I paid a lot of money for my portal and it’s supposed to be scalable.

• Some defects may not show up until load is introduced.  Memory leaks seldom show up in development and system testing.  They can easily bring down your production portal and be very difficult to track down.
• Tuning your capacity means you can control can get the most out of investment with the fewest number of production servers.
• The portal may not be the bottleneck under load.  It could be a connected database, web service, LDAP repository, etc.  This gives you a chance to identify and resolve those issues before going live.
• Quicker response times mean happier users, business stakeholders and executive sponsors.

What are some load testing approaches I should consider?

• Perform a baseline test before installing any of your custom code, components or configuration.  This will allow you to know what the portal can handle and surfaces any configuration and installation issues that might contribute to poor performance.
• Introduce load until the system crashes.  Determine what caused the crash, fix the issue and then load test again.  Continue to repeat this process until the crash cannot be fixed.  This allows you to tune for maximum scalability.
• Perform long term soak tests which run for days or longer using loads consistent with expected usage.  This will surface performance impacts that may not show until over time such as slow memory leaks.
• It is not necessary to test unrealistic scenarios, e.g. 1000 users log on and immediately log off over and over again.  This would not be a typical usage pattern of your users.

Do you have any other hints and tips?

• Portal is all about integration and likely connects with a number of other systems including databases, Web Services, an LDAP repository, etc.  Make sure the stakeholders of those other systems and services are made aware of testing and efforts and timing are coordinated.  You may need a DBA to monitor a database, if a connected service crashes you will need someone to restart it, or you certainly would not want to risk bringing down a production system or network due to a test.
• If your portal is highly personalized, you will need a large bank of representative test users.
• Create a test plan and share it with the implementation team.  They will be able to help validate the scenarios and point out any missing or non applicable ones.
• External facing or distributed portals may have bandwidth or latency constraints on the clients.  If this is the case, it is a good idea to account for it in the testing scenarios and evaluation.
• When troubleshooting a poor performing page in a portal, selectively remove portlets and content from the page to isolate the problematic portlet or content.

Performance testing is not difficult but it does take a large and coordinated effort among many different teams.  Plan early in your project for a comprehensive performance test and you will place yourself in the best possible position to deliver a highly scalable and fast performing portal.