Real-time analytics was the trickiest part of our load testing tool. We went through many issues and learnt lessons from that.
Requirements When we first started to think about real-time analytics, we though that our previous experience in load testing would help us to get quickly to something working fine. It always seems easy to rethink about a problem you already solved in the past. We were totally wrong.
We wanted to provide our users a completely new analytics experience when load testing their website. Our requirements are :
Real-time: users should not wait the end of the test to analyze results, Blazingly Fast: users should experience sub-second response times, regardless of the number of concurrent virtual users, Scalable: we must be able to scale horizontally as the number of users grows, Reliable: the analytics system should be redundant to provide fault tolerance and avoid outage, Testable: we should be able to easily verify through unit testing that the analytics system is working correctly, Open-source: we don’t want to build this by ourselves.
Which load testing tool between Apache JMeter and Gatling Tool best suits your needs? Learn the key differences between those tools and make your choice.
I think you’ll agree when I say:
It’s REALLY hard to decide whenever JMeter or Gatling Tool should be used.
You’re probably wondering:
How does JMeter to Gatling Tool compare? Which tool has best documentation? Performances? Script Maintainability? Should I use JMeter or Gatling? Or maybe both? Well, it turns out you can gain significant insight on JMeter and Gatling differences in just 5 minutes reading!
Following up our article about why we chose JMeter to build OctoPerf, our Cloud Load Testing Platform, this post compares JMeter and Gatling Tool on many different fields:
When building a startup, is it really required to write crappy code to quickly get a working product? We don’t think so.
OctoPerf has been built from the ground with one unique idea: writing code that’s pleasant to work with. Code quality is our number one priority. When you create your own startup, you quickly understand that the number one enemy are not your competitors: it is yourself!
When creating a startup you realize that your product:
must be released as quickly as possible on the market, needs as many features as possible to catch back the competitors, must be bug free to give your users the best possible experience.
Performance improvements are great. But, they inevitably come with trade-offs. Know them and you’ll be safe.
Everyone knows that having a website which is fast is better than slow. But, did you know that improving the speed of your web application almost always comes with a trade-off?
Like Antoine Lavoisier said Nothing is lost, nothing is created, everything is transformed. What happens when altering a web or mobile app to improve its performances?
How fast do you want to be? First of all, you should ask yourself this question.
How to host a static website with Jekyll on Amazon S3 and Cloudfront? Get the best performances from anywhere.
Our need is to create a fast website, in as less time as possible. Time is money, and when you launch a Startup, it is a very scarce resource.
Best possible response times from anywhere in our geographical market (Worldwide: USA, Europe and India). An already designed website template, we are not CSS gurus, and building it from scratch takes too much time. Easy to customize, it must match our graphic design with just a few modifications.
Website pages loading speed is more and more important. It is a Search Engine Optimization (SEO) ranking criteria since 2009.
The visibility of a website or a web page in a search engine’s unpaid results depends on its loading speed. Since 2010, Google announced that Webmasters should optimize their web pages loading speed because it’s going to be a ranking criteria: Page speed and Search Engine Ranking. Matt Cutts predicted this change on his blog.
Moreover, global website performance is also important for your visitors. Most people dislike when a website is stuck loading the page, and leave without coming back.
Dilemna choosing between open-source load testing solutions: JMeter, Gatling or building a virtual users injection engine from scratch.
When we started to think how to build OctoPerf, about one year ago, we had several options to create our stress testing platform:
Write our own HTTP engine from the ground, Use command line tools like Curl, Reuse an existing open-source HTTP engine, but which one? (Gatling Tool, JMeter, Grinder…) It took us several months to choose which one was the right option. When you are building a startup, the biggest constraint is obviously Time.
OctoPerf, our Cloud load testing tool, is made using massively open-source technologies. Because sharing is caring, this blog is a way for us to share how we made it.
We are proud to announce the opening of our Tech Blog. We really wanted to have a place to share technical thoughts openly. Why so open? Sharing technical stuff on our platform is like releaving secrets about how we built OctoPerf, our SaaS load testing tool.
OctoPerf wouldn’t exist without the open-source community.
We are widely using open-source technologies to build better software. It would be unfair to keep all the great things we have done with open-source technologies just for us.