Performance Lab and the Trouble with Passing Tests

A test can pass for an embarrassing reason: it has asked too little. The software answers the requests, the chart behaves, and the release meeting ends pleasantly. Then the actual audience arrives with its inconvenient habits. Everyone wants the same thing, at the same time, through a system whose reassuring rehearsal bore only a passing resemblance to opening night.

That is the territory Performance Lab occupies. Its old name sounds agreeably scientific; its current public identity, PFLB, is shorter and less patient with vowels. The company tests software under pressure, helps find performance bottlenecks, and supplies the cloud machinery for customers to run their own tests. It operates where a product’s ambition meets the rather less romantic question of how many requests its infrastructure can handle.

The crowd is the experiment

Load testing means giving software a simulated audience. But an audience is more than a head count. People pause, submit forms, call APIs, return to pages, and collide with shared resources. A thousand visitors reading cached pages represent a different proposition from a thousand people trying to register. The interesting question is what those people are asking the system to do.

PFLB’s documentation lets users construct tests from browser traffic recordings, JMeter scripts, Postman and Insomnia collections, and Google Analytics data. Developers can configure the workload, run it, and examine the results. The attraction is practical: existing knowledge of the application becomes material for an experiment, rather than something discarded when the testing tool arrives.

Its performance services add an engineer to that machinery. The published deliverables include an agreed workload model, scripts the customer keeps, a report identifying bottlenecks and proposed fixes, and a rerun after changes. That last item gives the engagement a useful ending. A recommendation has to survive the next measurement.

A small office, a very particular problem

In a GoodFirms interview, founder Yuri Kovalov traced his interest to core banking performance optimization. He had worked as a performance engineer before starting Performance Lab in 2008. His account describes modest investment and a small Moscow technopark office. The initial focus was narrow: testing and analyzing the performance of software and IT systems.

The present business combines a subscription product with project work and managed services. Its current website describes engineering teams in the United States, United Kingdom, and Iceland, and reports serving more than 300 companies. Performance remains its center of gravity, even as its services also cover broader quality assurance, automation, benchmarking, and data masking.

There is a sensible commercial logic here. A customer with performance engineers may need cloud execution. A customer without them may need someone to design the experiment and interpret it. Selling both gives PFLB two ways into the same problem. The buyer can purchase infrastructure, expertise, or a combination - depending on what the team can already do.

The tests acquired a constituency

One mobile automation case describes a global dating app releasing updates every two weeks. PFLB joined in 2016, using Apple’s XCUITest and Android’s Espresso. The company reports automating about 20% of functional cases and cutting full regression time by roughly 30%. A modest fraction of the suite produced a larger reduction in effort.

Then flaky UI checks began obstructing developers’ pull requests. PFLB’s response was a Test Orchestrator: individual tests could be disabled without changing source code, while new or repaired checks needed ten consecutive passes before entering the blocking CI pool.

The inference is useful beyond testing. A control that repeatedly obstructs reasonable work invites people to remove it. Teams need a way to investigate troublesome checks while keeping the release process moving. Quarantine also needs an owner and follow-through; otherwise a temporary holding pen can become a retirement home for inconvenient evidence.

September arrives on schedule. Storms do not.

FolderWave provides a different kind of deadline. Its educational services face recurring registration demand. PFLB’s account describes a College Board workload of 1,000 questionnaire submissions per hour, followed by a 2023 MEFA Pathway test asking whether 800 users could register within five minutes. Those are two different traffic measures, and neither should be casually exchanged for the other.

Testing exposed high response times in a service’s basic configuration. FolderWave could repeat runs through the platform while investigating and adjusting the setup. Here, the business calendar supplied the experiment: prepare for a concentrated registration event. “Scalable” became a specific action, volume, and time window.

For Pedernales Electric Cooperative, the event was a storm. PFLB’s updated case describes testing its Storm Center and outage reporting system with 10,000 virtual users inside one week. KUBRA supplied the infrastructure. The testers had to arrange IP whitelisting so throttling would not distort the run. They identified response-time spikes before deployment.

A test has to resemble the day you fear, closely enough to change what you do before it arrives.The editorial takeaway

The comparison is revealing. Education offers a scheduled surge; a utility must prepare for an abrupt one. The common skill is translating a situation into a credible workload. Coordination with an infrastructure provider can matter as much as a clever script. Without the right access, the test may measure a protective barrier instead of the application behind it.

Buying the rehearsal

At the time of this profile, PFLB lists monthly platform plans of $149, $249, and $399 per seat. Each includes virtual-user hours and AI report credits, with separate overage rates. A $299 Kickstart offer includes onboarding, 500 virtual-user hours, and one AI report credit. Its runnable-test guarantee has stated setup and timing conditions.

Engineering services use a different calculation. PFLB quotes projects individually and describes fixed-price and time-and-material arrangements. It also offers ongoing testing support and help developing an internal performance testing practice. Buying a subscription does not, by itself, buy an engineer’s investigation of an unfamiliar system.

That distinction helps place the company in the market. Teams can operate Apache JMeter themselves, choose a hosted platform such as BlazeMeter, or use Grafana k6 and its cloud service. PFLB’s proposition combines its platform with people who can carry out the work. The useful comparison is the cost of the whole experiment: setup, execution, interpretation, changes, and another run.

For a team already equipped to maintain its own tests, additional services may add little. For a team facing an unfamiliar architecture and a looming release, the engineering component may be the principal purchase. In either case, a beautifully executed test with the wrong traffic mix remains an expensive answer to the wrong question.

The report gets a new author

In April 2025, PFLB announced AI Reports: automated analysis and write-ups with interactive graphs and links that recipients could open without registering. Its stated internal estimate was a saving of up to 10% of working time. Treat that as a company estimate, rather than a result every buyer should expect.

“We built AI Reports to help engineers deliver smarter load testing results faster.”Yuri Kovalov / April 2025

The release notes show the product’s direction: report editing in 2024, anomaly detection later that year, AI reporting in 2025, and a December update supporting multiple JMeter scripts in one test and more control over report generation. The company also published a Claude and MCP testing walkthrough in August 2026.

Clearer reporting can shorten the distance between an engineer seeing trouble and a manager understanding it. Yet choosing the experiment remains consequential. The reader can copy the habit without copying the vendor: name the critical event, write down the workload, agree what failure means, and repeat the same test after the repair. The gratifying green chart can come later.