No matter how experienced you are, it’s easy to get terms mixed, confused, and misunderstood. To help, we’ve prepared this brief primer on performance testing vs stress testing to define these common terms (and a few others). You may still hear some of these terms used interchangeably, but at least now you have ammunition to correct others when you’re feeling pedantic. <grin> Let’s start with load testing.
For an e-commerce site, performance is key, especially during peak traffic periods. We often talk about preparing for Black Friday and Cyber Monday as traffic peaks. But realistically, those days aren’t the only days where traffic peaks.
(Warning to readers: this article is long and rambling, like most articles by the same author)
Once upon a time, I wrote a very simple command-line load testing tool in C. I called it "myload", partly because it was written by, well...myself, and partly as an allusion to MySQL (this was back in the days when MySQL ruled and I had yet to start using PostgreSQL).
The concept of load testing seems simple. You just run a test against your app, API or site and see how it performs under a simulated user load. But the reality is slightly more complex. There are three load tests you must run to optimize performance.
In the previous article in this series, we talked about getting prepared for your performance testing by:
- Creating user scenarios
- Configuring and running smoke tests
- Creating load tests
At this point, you’re onto the actual testing. You’re running load tests and finding actionable data in the results.
We’ve broken this phase down into six parts, but it’s important to remember that each part may require multiple iterations. But hey, multiple iterations of each step just means you’re continuously finding new features to optimize or new problems to fix, and that will only improve the user experience in the long run.
For anyone who’s played around with the programming language, Perl, you’re probably familiar with the motto, “There’s more than one way to do it.”
That’s not just true for Perl, though!
Depending on how you configure your load tests, you’ll see that your website/application and infrastructure react differently. That means running a diverse range of tests produces multiple outcomes, and more data is almost always a good thing.
As the leading cloud-based performance and load testing solution on the web, Load Impact is all about helping developers understand how their projects will perform in various situations.
Nearly every IT professional and manager is faced with justifying budget requests depending on their role within an organization.
Unfortunately, while IT staff is good at determining where to spend their resources, selling it to upper management is not always easy. What many of them overlook is that they can increase proposal success rates today by incorporating hard data.
A question that I have been asked countless times in my career has been, "Does your product/service have an API or scripting language?" Sometimes it's just a developer in the back of the room trying to look smart, other times there might actually be a legitimate business reason for an extensible architecture. In the case of a few solutions I worked with, the answer was, "Yes, but you will probably never need or want to use it."
Does Real User Monitoring eliminate the need for synthetic performance testing and monitoring? Not for environments where scalability and resilience to load are just as important as end-user experience.
The two approaches come at slightly different problems and generate different types of data but also have some overlap which may cause confusion with IT staff when making purchasing decisions. Hopefully, in this post we can help better define the two approaches.