Skip to content

Load Testing Blog

Are you buying Quality software?

In our previous article, Building Better Software, we have already shown how clean we try to maintain our codebase. We strongly believe that it's possible to run a successful business and have clean code at the same time. While it's relatively easy to show some nice metrics a single time, it's much hard to keep your code clean over time.

Even if we release some major features like On-Premise load testing, we still follow the boy scout's rule: Always leave the campground cleaner than you found it. Clean Code is not only compatible with business needs, it's almost mandatory if you want to be quickly competitive on a given market.

Unlike most software companies who don't really care about the quality of the software they ship, we do care that you get the best bang for the buck load testing tool. Do you know any other software company which regularly publishes code quality metrics? Probably not. We're trying here to introduce a new movement in favor of clean code.

What is Clean Code

Clean code

Clean code focus developing software that's easy to read, maintain and evolve. Good programmers have quickly understood that we are writing code for humans, not computers. Dikjstra, a famous mathematician, told something very interesting in 1972 at the Turing Award Lecture:

Continuous Integration Load Testing with Jenkins

We're proud to announce that we released our Jenkins / Hudson plugin to run load tests from your favorite Continuous Integration / Continuous Delivery service. The sooner you detect a performance issue the quicker the bottleneck can be found and fixed.

We believe that Continuous Integration Load Testing is the key to help companies deliver high performance web applications in time. Applications today not only need to pass unit and integration tests to ensure proper operation, but also acceptance tests like performance tests to ensure it behaves correctly under load.

The new OctoPerf Jenkins plugins allows you to leverage the power of our hybrid cloud / on-premise load testing solution as part of your development / testing build cycle. This significantly simplifies load testing web application for developers and testers. Each load test can leverage the power of our infrastructure to run thousands of virtual users.

Our highly scalable infrastructure will take care of launching as many virtual users as you need every time you run a Jenkins build. It makes load testing large scale web applications on a regular basis significantly easier.

Regression Testing

Continuous Performance Testing

Cloud testing vs Internal testing

The rise of cloud platforms lead to a major evolution for load and performance testing. Since generating load requires a powerful infrastructure for a short period of time, one might even argue this is the perfect use case. But since we started OctoPerf we had a lot of feedback from users wanting to test from their own machines for a lot of good reasons.

Web application does not mean web-site

First of all, not all web applications are available on the internet. In particular test environments, which are usually mostly meant to be used internally. As testing the application before its deployment is important, the load tests are often done on such environments.

Also, large companies have a wide range of intranet applications that can't be accessed from outside their network. Of course they need tests and in that case testing from the cloud does not make much sense.

  • in DevOps
  • 2 min read

Building small Java Docker images

When you take a look at the Java Official Docker images, you will immediately notice how fat they are: a whopping 243MB announced for a simple Java 8 JDK base image! It takes forever to download them from a regular DSL connection here.

Usually, your Dockerfile for Java apps starts with something like: 

FROM java:8

MAINTAINER ...

Just try the following command: (you must have docker installed)

docker pull java:8
docker images | grep java

Should I test my external providers

If you ever recorded a load testing scenario on a website you probably noticed that the list of external links can be scary: Server List

Plus these links might occur several times, making your user profile difficult to read. Because of this even a simple task like separating the different steps into distinct transactions can become tedious: Lots of requests

Every time I work on such tests the question is always the same: "Do we need to simulate these requests?"