It’s the fear of anyone who has launched a web site or an application that has any possibility at all of becoming well used.  What if your site can’t keep up with the load and the server crashes?  A crashing server due to resource overload can happen for a variety of reasons but today’s topic looks at how lack of testing can get you in hot water.

What Happened

In the early days of portal, we helped develop an employee portal for a well known fast food franchise.  One  portlet on the homepage was of medium complexity and required some complex logic.  As  part of the process, the portlet went through your typical system test process.  It passed with flying colors. The portlet did everything it was supposed to do. The portlet was then placed on the homepage in the production environment.

Not long after, the server crashed.  Then it crashed again. Deeper analysis pointed to this portlet.  We dispatched one of our brighter consultants to take a look at it.  Damian had to look fairly deep in the code to find that the original developer had coded an infinite loop that began sucking up resources every time it was hit.  Since this portlet resided on the homepage, it was hit fairly often.  The continual load placed on the server by this infinite loop eventually brought the server to it’s knees.

An infinite loop in your code can bring your site to it's knees

Revolutionize Your Business With Generative AI

From product design and software development to virtual agents, content creation, and reporting, GenAI is transforming business. Our AI experts help you unlock GenAI’s full potential and drive growth.

Let’s Get Started

What Should Have Happened

This one example highlights both an issue common to software in general and of particular import to the portal world.  If you use on physical server to host multiple portal sites, then one rogue portlet or web part can bring down not just one but multiple sites.   For this very reason, many companies decide to eschew the use of virtual servers and pay the licensing and hardware cost for separate physical infrastructure per site.  That of course kills much of the ROI you hope to gain from using a portal.

You can minimize the risk of a rogue portelt bringing down your site(s) without developing a hugely expensive infrastructure.  The key of course is testing.  You must perform a series of tests to catch all the possible errors.

1. The developer should perform unit tests to ensure that whatever he or she delivers will work.  I believe that one of the most embarrassing things that can happen is for a developer to deliver code that cannot run at all.
2. A testing team should perform string and system tests to make sure the portlet works as expected and that it doesn’t cause errors when working alone or in concert with the portal or other portlets.
3. The testing team should also do load and performance testing.  We find that many company’s prefer to cut corners with load testing.  However, the production issue above occurred because no load or performance testing was done.  If the team had put that homepage under continuous load for a couple days, they would have discovered and fixed the issue well before it was pushed to prod.

So the lesson here of course is that you can gain a lot of value from portal and share environments but that you should only do so if you do load testing before you launch any new functionality that has the capability of causing issues like server overload.

Previous Installments

1. Where’s My Homepage?!?
2. The Business Asked for It
3. Methodology for Methodology’s Sake
4. The Never Ending Strategy
5. I Built It But Now I Can’t Support It
6. We Can Get Big ROI From a Portal
7. Is Best of Breed Always Best?
8. When Developers Can’t Develop
9. When Not to Use a Portal
10. When Web 2.0 is 2.Much

Join us this month on Wed, June 29th for our Perficient Perspectives webinar in which we explore the 12 Things You Shouldn’t Do on a Portal Project in depth.  More Info / Register