Skip to content
  • ZipCode Api
  • Blog
  • About RedLine13
RedLine13
Primary Navigation Menu
Menu
  • Start Testing
  • Demo
  • Pricing
  • Docs
    • Knowledge Base
    • AWS IAM Setup Instructions
    • Running a RedLine13 Load Test with Advanced Options
    • Scalability
    • Writing Open Load Tests in Your Language
    • Jenkins Plugin Setup
    • AWS Approval for Large Tests
    • Pro Features
  • JMeter
  • Partners

#6 How it used to work

By: Rich Friedman

From the Open Source Load Testing presentation http://www.slideshare.net/richardfriedman/open-source-load-testing

True story, but leaving out a few company specific details.  One of my first entries into managing larger teams was a project which had 40-50 developers and the middleware needed to support thousands of transactions per second.  The system was built with the work of a great team and the expertise of one amazing project manager, but we needed to start load testing.

Realize this was circa 2004, so pre-cloud.  It was a large company and we had a testing environment, however, that was shared.  Want to run tests?  Get your test ready, get time scheduled, run your tests, and go back and analyze results.  No matter when you run your load tests during your software development lifecycle, it is never one and done.  You need to iterate over and over, so sharing a testing environment was a painful experience.

As a resourceful team and having been deep into the java community, we knew of two projects at the time Grinder, now called, ‘The Grinder” and JMeter.  I don’t remember why, but we selected Grinder.  We built the scripts to test our middleware API and we tested from a single machine.  Next step was scaling the load test.

Since we had a team of 40+, we commandeered every desktop, distributed the load test script to everyone via email with instructions on setup and execution.  When it was time to load test, everyone got to their command line (cmd – it was all Windows desktops) and started the java command to launch the test.   As this project was ages ago, some of the details of how we aggregated the results or analyzed data escapes me, however, the process allowed us to iterate our load testing. .

  • The Grinder.  Open source load testing tool used to run the tests, deployed to each developers machine
  • User.  While the grinder tests ran a few people where examining the response time from their terminal
  • Minions.  To launch the grinder tests we had to communicate with everyone to get the test ready
  • Servers. Our staging environment, which was similar, but not a mirror of production

When it was time to validate our results on the larger, more expensive environment, we still found some issues, but we reduced the cycles we needed to spend in a shared environment

OSLT_HowItUsedToWork

2015-09-02
Previous Post: #5 Load Testing Priority
Next Post: #7 How it should work

Recent Posts

  • Use Cases for the JMeter Dashboard Report
  • AWS Costs for Large JMeter Load Tests Run by Real Customers
  • AWS Multiple Account Setup for Load Testing – Securing your Application Environment
  • Merge Results for Data Analysis
  • Debug your JMeter Test with Output Files

Related

  • Free Load Test Trial
  • SAML SSO
  • E-Learning Companies and Load Testing
  • AWS Multiple Account Setup for Load Testing – Securing your Application Environment
  • AWS Costs for Large JMeter Load Tests Run by Real Customers
  • Why BlazeMeter Customers Chose RedLine13
  • Is BlazeMeter Scared Of RedLine13?
  • RedLine13 Customer HBO Latin America Speaks at Customer Advisory Board Meeting
  • ThinkLogic and High Volume Tests on RedLine13
  • Why ACT Moved from BlazeMeter – Highlights from the RedLine13 Customer Advisory Board Meeting

© RedLine13, LLC | Privacy Policy | Contract
Contact Us: info@redline13.com