At a glance
- Client: FolderWave, Inc., a leading digital services provider in the Massachusetts e-learning sector, helping millions of students research and plan a job-oriented education
- Partners whose systems carry the load: MEFA Pathway and College Board, connecting a vast network of colleges, schools and universities across the US
- The predictable peak: every September, FolderWave expects at least 1,000 students to register simultaneously on MEFA Pathway after major online events, with a similar volume of questionnaire completions uploaded on the College Board system
- Scenario 1 (College Board): emulate 1,000 questionnaire submissions per hour
- Scenario 2 (MEFA Pathway, commissioned in 2023): confirm that 800 emulated users could register within 5 minutes
- Who commissioned it: Bob Burke, president and co-founder of FolderWave
- What was found: the basic configuration of one of the services needed adjustments because of high response times under stress conditions; engineers ran root cause analysis and made timely optimizations
- The lasting part: PFLB's cloud service let FolderWave's own team repeat the tests multiple times to tune the configuration for the expected load, without a new engagement each time
- Outcome: the peak load was successfully managed
Why September is the whole year
The educational process is cyclical. At the beginning of academic terms, large numbers of students create portfolios, plan study budgets and consider career paths all at once - and they do it inside FolderWave's partners' systems, which puts those systems under significant strain in a narrow window.
FolderWave's business model depends heavily on the number of active users on the platform, and after the global shift to online learning following COVID-19, the company has been increasing its target audience exponentially. That combination is what makes this a real risk rather than a theoretical one: the audience grows every year, the peak arrives on the same date every year, and the systems carrying it belong to partners like MEFA Pathway and College Board whose names sit next to FolderWave's. Any failure in these critical e-learning systems could severely damage the company's reputation and its financial standing - and it would happen in front of every student and every partner institution simultaneously, on the one day the whole sector is watching.
So Bob Burke, FolderWave's president and co-founder, hired a PFLB performance and load testing team to emulate the two typical user scenarios that happen annually.
How the scope was set - before anyone tested anything
This is the part worth copying. The FolderWave team understood how their new users interact with the services, and they predicted the peak user load themselves. The engagement was then written against those predictions:
The test run in PFLB Platform: throughput and response time for the registration service under load.
- College Board: emulate a load of 1,000 questionnaire submissions per hour.
- MEFA Pathway (the second engagement, in 2023): confirm that 800 emulated users could register on the platform within 5 minutes.
Two systems, two numbers, two time windows. No open-ended discovery phase, because the client brought the target and PFLB brought the means of hitting it.
“That's why I'm happy to use PFLB's services and platform. It provides a simple, reliable tool that helps us ensure and improve the performance of the MEFA Pathway registration service and College Board questionnaire system.”
Bob Burke, President at FolderWave
What was found and what changed
PFLB engineers conducted the initial performance testing on the PFLB platform and then shared access to the test results with the FolderWave team. The cloud service let FolderWave repeat the tests multiple times on their own, tuning the configuration against the expected load.
Running them, FolderWave's team discovered that the basic configuration of one of the services needed adjustments, because response times were high under stress conditions. The engineers then carried out root cause analysis and made timely performance optimizations.
That is the sequence a buyer should want: the vendor establishes the measurement, the client can reproduce it, and the fix is aimed at a cause rather than at symptoms.
Results
- The peak load was successfully managed - proactive performance tracking of the company's e-learning IT services did what it was bought to do.
- Timely load testing strengthened FolderWave's reputation as a reliable e-learning service provider, with both partners and students.
- Outsourcing the testing process saved FolderWave's engineers valuable time.
- The cloud-based load testing tool provided quick results without compromising security, and allowed repeatable testing so issues could be tracked and resolved consistently.
Questions this engagement answers
What actually determines the cost of hiring a load testing company?
Four things, all visible here. Scope: this engagement covered two scenarios, not two platforms end to end. Whether the target is known: FolderWave predicted its own peak - 1,000 submissions per hour, 800 registrations in 5 minutes - so no discovery phase was needed to find out what to test for. Whether repeat runs need the vendor: they did not, because the cloud platform let FolderWave's team rerun the tests themselves while tuning the configuration. Infrastructure: cloud-based testing meant results were viewed in PFLB's tool rather than on hardware the client had to stand up. A quote for a bounded, target-defined engagement like this looks very different from an open-ended retainer, which is why the first thing to nail down with any vendor is the scenario list and the numeric target.
Is outsourcing cheaper than testing in-house?
The comparison is not vendor fee versus zero - it is vendor fee versus your own engineers' time plus tooling plus the infrastructure to run it. Here outsourcing saved FolderWave's engineers valuable time, and the client kept the ability to rerun the tests afterwards, so the spend bought both an answer and a capability.
How do you decide what load to test for?
From the business calendar, not from a benchmark. FolderWave knew September brings at least 1,000 simultaneous registrations after major online events, and that a similar volume of questionnaire completions lands on College Board. Those observed facts became the test targets directly.
What does testing usually find in a system like this?
Configuration, more often than code. Here the basic configuration of one service produced high response times under stress, and root cause analysis pointed the optimization at the right place. See how PFLB approaches e-learning systems generally.
Do you know the date of your own peak?
If your busiest hour of the year is on the calendar, it is testable months in advance - and the target should come from what you already know about your users, not from a generic benchmark. Two scenarios and two numbers were enough here.
