Troubleshooting Archives – LoadStorm

Many of the errors will be HTTP status codes which can easily be looked up on wikipedia or RFC 7231. Some of the errors you encounter will not have an HTTP status code. These errors are defined by LoadStorm.

Common HTTP Status Codes

• 400: Bad Request – A VUser sent a request that is not properly formatted.
• 401: Unauthorized – A VUser failed authentication to access the target server.
• 403: Forbidden – A VUser lacked the permission to get a resource.
• 404: Not Found – Usually the link is invalid due to a typo, stale token, or the file does not exist.
• 500: Internal Server Error – Usually indicates the target server is having trouble with the load or something is wrong with the request.
• 502: Bad Gateway – Could be a configuration issue with target server.
• 503: Service Unavailable – Your server is barely functioning, and can only respond with this status code.

Common LoadStorm Error Codes

• Request Read Timeout – The request may have begun to respond but was cancelled when it reached the customizable timeout limit.
• Request Connection Timed Out – A VUser couldn’t establish a TCP connection to the target server after 10 seconds, and this limit is not adjustable.
• Socket Connection Reset – The connection was reset by the target server via a TCP reset packet which breaks the connection immediately.
• SSL Handshake Failure – The request was cancelled because it was unable to establish a secure connection possibly due to an obsolete cipher suite or mismatched SNI.

Unfortunately we do not have a method yet for handling the WebSocket protocol. LoadStorm can still make the HTTP request that would initialize the handshake for the WebSocket connection, but no connection will be made. There are two issues that arise with WebSockets. Handling the non-HTTP protocol, and deciding when to terminate the connection. The connection usually remains open until the visitor has completed some action or prematurely departs the site.

Our QuickStorm feature is meant to help give a quick demonstration of what our reporting will look like during a test run. To make this process as smooth as possible we remove the task of having you make a browser recording, saving it as a HTTP Archive (HAR) file, uploading it to LoadStorm to be converted into a script and scheduling a test run. Instead we take a URL you provide and feed it into an automated process that handles these steps for you. Anytime you try to feed in complex elements into an automated process there are bound to be some issues that may prevent the process from completing.

Sometimes these are simple mistakes:

• typo mistakes in the URL
• requesting URLs using HTTP when they need HTTPS
• private URLs
• local IP addresses
• URLs that need basic authentication credentials

Other times there are more complex issues with the automated tool handling the page given to it. Usually this is due to how it fails to parse something in the page:

• handling WebSockets
• malformed html
• javascript errors
• streaming audio/video
• failing to make a connection for a requested resource

Many of these are not an issue with real browser recordings. So if you encounter a problem please use the LiveChat button at the top of the QuickStorm test and ask for assistance, or email [email protected] to request a demo. Otherwise we encourage you to check out this guide for getting started with LoadStorm to create a real browser recording and run your first load test instead of a QuickStorm.

Depending on the test requirements, third-party servers should be set to “Ignored” or “Archived”. Requests that would go to ignored or archived servers will be skipped instead. Skipped requests prevent unnecessary traffic to advertisements, analytics, or other third-party services. You may encounter a server already set to ignored as a part of our blacklist. Please contact [email protected] about enabling a blacklisted server for your testing needs.

Ignore a Server

Please note that by ignoring a server, any requests normally sent to that server will not be sent.

1. Click on the Build menu, then on the Server tab on the top.
2. Double-click the server you want to ignore.
3. Click the Ignore button. No requests will be sent to this server.

Archive a Server

Archiving a server works the same as ignoring a server, but it’s a separate category. This way you can separate the servers you may never need to test from servers that you may not want to test at the moment. To reiterate, archiving a server means it is ignored. Any requests normally sent to that server will not be sent.

1. Click on the Build menu, then on the Server tab on the top.
2. Click the server you want to archive to select it.
3. Click the Archive button. No requests will be sent to this server.

LoadStorm PRO does not use a browser emulator, nor is it a full browser. Instead, it takes a HAR recording and builds a script from the recorded network requests to mimic a real browser while still allowing for a competitively costed solution. LoadStorm PRO also supports AJAX requests as well as REST and SOAP API calls. If we used an actual browser, we would trade-off the cost effectiveness of our solution for the ability to actually process javascript and other interactions exactly as a browser. Some solutions use actual browsers and cost you a great deal more money.

We understand some web developers need real browsers and are willing to pay for it. Our load testing tool is designed to help those developers that are willing to achieve their load testing goals without a full browser and at a much lower cost.

Yes, there are two additional ways for you to white list our traffic:

1. You can customize the user agent for each script which your firewall can see in the request headers of inbound requests. However, if your test scripts contains HTTPS requests, then those headers will be encrypted. Visit our learning center for more information on modifying a script’s default settings such as the User Agent.
2. If you are not testing against your production server, we recommend trying a non-standard port number to identify the traffic as load testing. LoadStorm allows you to use any port number and can be designated for each target server.

Yes. Once you’ve created a script, you may modify form POSTs in order to log into your application with test user data.

We recommend you visit our learning center, where we go over all of the options for parameterization in a script. A brief explanation is given below, but we also offer video tutorials on common examples such as parameterizing a login form.

While creating a recording using developer tools in your browser, log into your application, and save the recording as a HAR file. Then upload the recording into your LoadStorm account. Open your script and select the parameterization tab.

After that, click BUILD in the left navigation and switch to the User Data tab at the top. Here you can upload your CSV which contains necessary login info (username/email, passwords). Note that the first row’s data will be read as column headers and not row data. You can also choose to “generate data” on-the-fly in LoadStorm. If you need to embed a comma inside a particular data field, simply place quotation marks around all field data in the file.

Finally, edit the necessary script and find the POST request that submits the form. Modify the form to include Custom Data with CSV user information. To add the test user data, you must select “custom” under the form modifications options, and select the data from a CSV file.

This simulates traffic more realistically. Instead of simulating one user logging in over and over, many different users log in instead.

Unfortunately not. LoadStorm is only for web applications that can be reached from the Amazon cloud. If you have an intranet application, then opening a hole in your firewall and providing a URL or public IP address that can reach the intranet application will allow LoadStorm to run load tests against it.