Rungutan - Fastest Load Tester in the jungle
We're officially launching the OPEN BETA stage of our newest Serverless Load Testing tool offered as a Software-as-a-Service (SAAS) platform.
This is the project we are going to present this month at Startup Spinner Makeathon 2019, a 72 hour competition designed to bring together the most valuable startups from Romania's N-E startup scene.
In order to showcase the most critical strengths and flaws of our project, developed for all DevOps and QAs out there, we would really like some feedback from you guys, the ones that are going to actually benefit from using it.
This tool is free of charge of course, for the OPEN BETA version, so test it while it's hot!
Why did we create this project?
Here at NETBEARS, we do DevOps consultancy on a day to day basis.
While building our infrastructure, we of course also had to test it. And of course, we took the usual path of exploring all available tools, write our tests, perform them and see the results.
But while using all of these "GIANTS" on the market, we've noticed a few small problems:
- The traffic was generated from too few external IPs and was blocked as an anti-DDoS measure -> ApacheBenchmark problem
- It was extremely expensive -> BlazeMeter costs a ton of money if you want to run for more than 5 minutes with more than 1,000 requests / second (around 200-300 USD / test)
- It has an extremely annoying learning curve -> Jmeter
Why should a DevOps or a QA care about it?
While some organizations are slower to adopt a complete performance testing strategy, they’ll quickly realize that having no strategy will negatively impact bottom line goals.
Here are a few of the ways that performance testing affects business ROI, according to Radware:
- 51% of online shoppers in the US say that site slowness is the top reason they’d abandon a purchase.
- Shoppers remember online wait times as being 35% longer than they actually are.
- A 2-second delay in load time during a transaction results in abandonment rates of up to 87%.
- The total cost of abandoned shopping carts for online retailers has been estimated at more than $18 billion per year.
- 64% of smartphone users expect pages to load in less than 4 seconds.
- When faced with a negative mobile shopping experience, 43% of consumers will go to a competitor’s site next.
What can this platform do?
In the OPEN-BETA we've tried to overcome all of these problems by:
- Offer the possibility to perform load-testing from UP TO 10 DIFFERENT EXTERNAL IPs.
- All tests boot up in a matter of seconds.
- You do not have to know any programming logic.
- Is extremely easy to integrate into any CI/CD tool.
- Offer the possibility to simulate workflows, in which our tool simulates users that performs multiple steps on your website sequentially, such as ["login", "add_to_cart", "complete_order", "view_order"], all this of course, multiple times.
FAQ
But first, a disclaimer
This OPEN-BETA project is offered free of charge for people to try out the software and share their thoughts and ideas.
It is however NOT intended to bring down websites that YOU DO NOT OWN.
If we do notice any misbehaving with our platform, we will ban your account!
What is Load Testing?
Performance testing is used to see how well a software can handle user traffic. By putting a simulated demand on an application or website, it’s possible to analyze breaking points and evaluate expected behavior. Specifically, performance testing is used to measure responsiveness, stability, scalability, reliability and speed.
As a code change from a team that is continuously integrating new features and bug fixes can impact how an application looks and functions on different browsers and devices, it can also affect how quickly that application loads across machines.
This is why performance testing is so crucial to a well-rounded QA strategy — checking an application’s performance and ensuring consumers are experiencing acceptable load time and site speed is foundational to high-quality software.
Performance testing also helps teams analyze activity so they predict traffic trends. This allows them to better prepare for breakpoints and site dropouts for the future.
Your data
We want to make sure that you know from the start that we DO NOT STORE in any database any of your payload data or request headers.
The only thing we store in the database are the actual test results, so that you can fetch them at any time and study them.
Can other people view my results
Of course NOT.
We use an API-KEY based authentication mechanism to ensure that YOU and only YOU can view your test results.
How do I test pages that require authentication?
There's already an option to also post payloads through the data parameter in each workflow step.
So in theory, one should be able to insert the username/password (or whatever authentication logic) in the payload for that.
Don't worry, we're not storing any payload or headers anywhere!
How do I exclude the fake traffic ?
You can achieve this by adding some specific argument to the URL, eg "?disregard=true", and then remove that type of traffic in Google Analytics.
A tutorial on how to exclude traffic based on Request URI is posted here and here.
Does your app just execute HTTP requests or actually render the page?
Our platform actually renders it :-).
A future version of this service will even let you use HTML elements (or response codes) in some workflow steps and specify them as "parameters" for the future workflow steps.
To make this clearer, you should be able to use the value of an HTML element with id=order_id and specify it in the payload for the next workflow step as a payload or header.
Final notes
This tool was made with ❤ by a group of DevOps, for a group of DevOps.
All feedbacks are greatly appreciated and highly welcomed!
If any questions, feel free to contact us using this form.