Skip to content

Load Testing Blog

Base tools for bloggers

To follow up on my article about creating blog based on Jekyll, Bootstrap4, Grunt, Bower and hosted on GitHub pages, I'm adding ways of measuring and increasing the number of visitors.

This article is a quick tutorial to do the same, starting from the blog template:

  • Get to know how many visitors are caught in your blog using Google Analytics,
  • Generate a Sitemap.xml using Jekyll and feed it to Google,
  • Embed Twitter buttons,
  • And use Disqus to handle your articles comments.

Load Testing Reports Exporting

This short post describes the modifications made to OctoPerf for its last update, and how they can help you save time while load testing.

Our goal is, and has always been, to ease the work of load testers. Creating test reports using Word / Excel can take a lot of time.

Exporting the report

That's why we automated this process in OctoPerf, our load testing solution. Even as your performance bench is running, you can edit the generated report:

  • List errors to check that your virtual users are properly configured,
  • Add various charts to identify performance bottleneck,
  • Insert text to explain what could be donne to improve response times,
  • Give your conclusions to the stakeholders.

You can have a complete test report, ready to be delivered, as soon as the bench ends. And now, you can directly export it from OctoPerf into a PDF file.

How can you tell that a web developer is working?

You can hear him Grunting!

The problem

I want my blog (the one your’re reading) to be statically and freely served, using my own domain name. I want it to be maintainable and easy to update. And first of all, I really do not have much time for this, so it must be up and running in a few hours.

The solution

Bye bye WordPress, Welcome Jekyll. I can handle a couple lines of PHP but it's not my cup of tea. And WP breaks the static rule, so as the maintainable one. I previously used Jekyll to create the OctoPerf website. And as you may ask yourself why the bad joke about Grunt: I used it with Bower to create the frontend of our load testing solution.

Jekyll is a really handy tool. The kind of tool that you can use even without first reading the documentation (my preferred kind!). And when you face a problem, the solution is placed in the first 3 results of Google. The first one often being their manual that you didn't read.
But Jekyll doesn't come with dependencies management, and the couple Grunt/Bower is to JavaScript what Maven or Ant/Ivy is to Java: a nice build solution.

One year using Java 8 in production

We've been using Java8 since the beginning of our startup. Java8 was released on 18 March 2014. We started using Java in September 2014, when AWS made it available on ElasticBeanStalk. At this time, Java 8 was available for almost 6 months. It was mature enough to give it a try.

Frameworks compatible with Java 8 like Spring 4.0 started to be available. Java 8 is a huge step forward compared to Java 7 :

  • Lambdas: concise way to write Function and Predicate, a step toward functional programming,
  • New Apis: Optional, Streams, Dates,
  • Default Methods: define default method behavior in interfaces.

One year later, what did we really use? How did we use it? These are some of the questions we're going to answer.

What about Guava

Guava is a Google Utility API. Before Java 8, we were widely using Guava's features like Predicate, Function, Optional and more. We feel like Java 8 brings almost everything what Guava is providing. We gradually replace Guava features by their Java 8 equivalent.

The question whether to keep Guava or not is a good question. Java 8 picks a great number of features from Guava, and it's not a surprise. Guava is one of the most famous Java API, just behind JUnit.

HTTPS should be the standard

OctoPerf is fully HTTPS. There is a are several reasons for it. Setting up HTTPS for all our websites (Documentation, Application and Website) is a little bit tedious and pricey1. It took us two days to complete the operation but the result is satisfying for number of reasons.

Why is HTTP so dangerous

HTTPS ensures that the communication between our servers and our customers is fully encrypted. Lots of people are using a Wifi connection to go on the internet. For example, if you connect from a HotSpot from Starbucks Coffee, the Wifi connection is completely unsecure. Any login or password transiting with non-secure HTTP protocol can be easily intercepted.

Software like Wireshark can sniff the network packets transiting over the Wifi connection, even if the communication is not targeted for your computer. It switches the network card to promiscuous mode: the Wifi card accepts any packet over the air.

HTTP vs HTTPS

How does HTTPS work

When surfing on an HTTPS secured website, the connection is encrypted from client to server. Only the server can decrypt what the client has encrypted. To make things short:

  1. The server sends a public key to the client,
  2. The client encrypts the request to send with the public key, and sends itself its own public key within,
  3. The server decrypts the request sent by the client using a private key, it encrypts the response using the client provided public key,
  4. Then the client decrypts the server response using its private key.

Okay, it's probably more complicated than that. But, we're surely on the right track.