False premise of failed transactions

by Perfluencer

image-4 False premise of failed transactions

Did you know that errors are usually the fastest transactions? Here’s why:

The system stops processing on the stack as soon as a technical or functional error occurs. The failure isn’t free either—it involves rollbacks of already started transactions, rollbacks of the stack, and additional, more verbose logging. However, in general, it’s still faster than a successful transaction.

Mixing the response times of both successful and failed transactions might not be the best option. The higher your error rate, the lower your latency. It’s even worse if your assertions don’t detect these errors, and you report a response time for a non-functioning application.

Now that I think about it, I may have found the origin of the term “non-functional” testing

Share this content:

I'm Kuba, a Performance Enthusiast and a bit of a blogger. I write performance engineering content in an accessible way, covering best practices and testing methodologies