In April of 2000, we were releasing the beta version of LearnCentrix. Alltel Corp. was our first client, and we had designed the system to their requirements. I remember the VP of Training asking me, “How many of our employees can be logged on at the same time?” Good question.
I thought about it and gave an accurate, yet indefensible, answer: “There is no system limit.” While I knew that we had no concurrent user restrictions in the code, and there were no configuration settings to enforce a contractual cap, I really had no idea what the practical limit would be.
We had focused on functional testing – getting all the bells and whistles added to meet the demands of Alltel’s project leaders. And with only a handful of clients trying out the new release, we had no concerns about load. But we should have been concerned.
About nine months later, Alltel had fully ramped up their usage in the system. Online courses had been created and incorporated into their call center training. A wireless company of that size has tens of thousands of employees that need to be trained. We assumed that web-based training would allow them to offer the courses “on-demand” when the new reps were hired. You know what happens when you Ass-U-Me. Big mistake.
They had thousands of new reps all going through the training in multiple sites across the globe…simultaneously. It was supervised and timed. Well, the timing part didn’t work out.
Our support lines started ringing. The app wasn’t dead, but it was barely breathing. Our servers were overwhelmed. The volume crushed us, and we had no one to blame.
This time when I discussed concurrent users with the VP, he nailed me down tightly. “We don’t know” was my answer this time. I was truly embarrassed. Our team was mortified. We all felt helpless. And our client satisfaction took a huge hit.
If we had been using LoadStorm back then, we would have been able to load test our web apps. In 2000, we couldn’t afford to buy the Mercury Suite for several hundred thousand dollars. We also couldn’t afford the racks of servers it would take to simulate the large volume of users. It just wasn’t feasible.
And we weren’t alone. And we still aren’t. Because small to medium software companies simply cannot apply the capital needed to build large environments for load testing. Now they don’t have to.
LoadStorm would have been a tremendous asset to our little software company. And although it has been eight years since that first server meltdown, LoadStorm is just as valuable to us today.
The key aspects of any web application that make it successful are:
- Does it fill a need?
- Is the solution cost-effective?
- Are there enough people that have the problem?
LoadStorm brings a viable solution to a real problem. And every development team that builds applications for the web must know how many users will bring down the system. Paying only for what you need is a beautiful thing. The ability to quickly ramp up and down without any data center hassles is just as important a cost saver.
LoadStorm is a price performer.
If a Development Manager doesn’t care about having a meltdown, then he or she doesn’t understand how quickly web app users can switch to other vendors. Such Dev Managers haven’t had the call with a client that I had back in 2000 with the Alltel VP. That pain stays with you. And that pain drives you to find a solution.