Load Testing Blog
Showing posts tagged “Load Testing”
Load Test Early!
Customers occasionally ask us “How early should we begin load testing?”
The answer is to test something, anything, as soon as the architecture is available. Performance problems have a wide variety of causes – from a single line of code to a load balancer setup; from a database schema to a server config file. Early in the development of the software you can catch simple coding problems and fundamental architectural limitations that are much easier to fix before a lot of code has been written.
Now, a word of caution: … Continue reading »
Performance Starts with the Developers
Performance starts with the developers as well as the server and network administrators. High-capacity websites do not happen by accident. To perform well and scale big, the system must be designed, built and configured for performance. That means it must be coded and configured with performance in mind, right from the start. Make sure the developer and admins all understand the levels to which the system must perform. Don’t make them guess what “it has to be fast” means.
Two of the most important tasks the test and project management teams to … Continue reading »
How much bandwidth can we expect from cloud engines during a load test?
I got into a discussion in the Performance Testing group on LinkedIn which raised a question that we had answered internally, but had neglected to share with our customers – how much bandwidth do our cloud engines have available?
Before I proceed, I must make this disclaimer: our cloud engines run on Amazon’s EC2 infrastructure, so the rules that apply there also apply to our cloud engines. Amazon does not make any guarantees for bandwidth, so anytime your test results look suspicious, we … Continue reading »
How HTTP Authentication works and why load testers should care
The most commonly used authentication method for websites is a login form on a web page. We’ve all seen them – enter your username and password into fields on the web page and press the Submit or Login button. From the standpoint of the underlying technology, this is no different than submitting any other form – only the names of the fields distinguish them as login or password fields and the security mechanism is implemented within the web application.
The next most common form is authentication via … Continue reading »
Load Testing Data Population: How Many Rows?
A common problem when setting up a load testing configuration in Load Tester is figuring out how many rows of data you need for a particular test. For example, you need to have a set of user names and passwords to be used during the test, but how many do you need to ensure that the test will complete?
To answer this question, you need to know three things: the duration of the test, the expected duration of the test case, and how many concurrent users the test will simulate. … Continue reading »
How To Manually Modify HTTP Requests in Load Tester 4.2
In older versions, Load Tester provided a simple interface for modifying the URI portion of an HTTP request. For example, you could add a query parameter or a path segment by adding it directly to the request line in the Edit HTTP Request-line/URL dialog.
In Load Tester 4.2, this process has been made slightly more complex but vastly more powerful. We’ll start by manipulating the URI field directly. To do so, select the specific transaction you wish to edit, then select the Fields View, … Continue reading »
Editing Datasets Made Easier in 4.2
In the upcoming release of Web Performance Load Tester 4.2 it is now easier to edit datasets. In previous releases of Load Tester, deleting rows of data required either selecting each row individually and manually deleting it or exporting the dataset to an excel spreadsheet, removing the data and importing the file back to Load Tester. With Web Performance Load Tester 4.2, you can now simply highlight all the rows you want to remove and click on the “remove dataset row” icon. Adding rows is just as easy, … Continue reading »
Load Testing Back to Basics: Avoiding the KeepAliveTimeout Race Condition
You’ve recorded your test case, configured your datasets, and run your replays. You start up the load test and … you see numerous errors like this:
“The connection with the server was unexpectedly closed before starting the response.”
What’s going on? Well, one common reason for this error is a connection-related race condition between Load Tester and the web server due to the server’s configured persistent connection timeout.
Persistent connections are an HTTP mechanism for minimizing network connection overhead between the browser and the web server. If the client … Continue reading »
Garbage Collector Performance under Load
The overwhelming majority of dynamic internet-facing applications are built on garbage collected runtimes such as Java and .NET. Garbage collection is popular because it promotes rapid application development. On the other hand, whenever a system is demonstrating unexpectedly poor performance, the garbage collector invariably surfaces as a possible suspect. Our advanced server analysis module even hooks into garbage collection performance monitoring on the .NET platform.
The reality, however, is that modern garbage collectors are very good.
Fact: Our company has been in business since 1999. In this time, no one can recall ever … Continue reading »
Drupal: Caching and Database Scalability
Note: This is Part 4 of an ongoing series on Drupal performance and load testing. If you haven’t already, read the introduction.
Summary
We measured Drupal’s performance with respect to database size, demonstrating flat performance regardless of the size of the database. We also got some good data demonstrating Drupal’s behavior with caching.
Procedure
We re-created our previous test platform: a stock Drupal installation on an Amazon Elastic Cloud m1.large instance with both the Alternative PHP Cache (APC) and Drupal’s built-in caching capabilities. In this test, however, instead of scaling the number of … Continue reading »
