Announcing support for Gatling on the Grid

The skinny

Here at Gridinit we’re avid followers of all things related to performance testing, and we’ve noticed a trend, or perhaps a split in the way performance test tools approach simulation of load for web and mobile applications. We see that split as follows:

  1. Full UI automation. Pioneered by the likes of Patrick Lightbody of BrowserMob fame, a growing trend is to whack it with lots of little sticks, or rather full browsers / emulators. Generally less value for money in terms of number of users per process (1:1) and not so great for the budget conscious tester.
  2. Thread based automation. The long favoured approach by vendors, whack it with a reasonably big stick and drive load at the protocol level with lots of threads stuck inside a process. JMeter does this and delivers good value for money, but soon hits limitations in resources. A reasonably complex test plan with assertions and listeners might achieve 300 users on a 2GB JVM before hungry threads start competing for resources.
  3. BFG9000 based automation. The biggest stick of all, we can’t put a name to it, something like a lightweight-process-actor-model-asynchronous-event-driven-concurrent-thingy … old concepts but essentially the most value for money in terms of parallel computing. Tools like GatlingLocust-IO, Tsung and Iago all achieve massive concurrency and throughput from a single VM with messages generally processed asynchronously in some form of event-driven loop. Thousands of users per VM is achievable.

The past

Gridinit was originally built with full UI automation in mind using watir-webdriver, but quickly shelved the idea as it became too difficult to deliver value for money without burning a hole in the Ozone layer.

The present

Gridinit took the middle road and already supports JMeter. Easy to scale out with Gridinit but what if you want to run a massive test of say 1M concurrent users. That’s a lot of JVMs!

The future

Gridinit is happy to announce support for Gatling on the Grid, to give our users more options for generating extremely high volume and high concurrency tests. How high? This short video demonstrates Gridinit spinning up 50K users on 8 grid nodes with over 5K requests/sec in just 5 minutes. Given we have 8 regions and at least 20 nodes per region that’s a lot of power at your hands.

We’re restricting use of Gatling to our Beta and Paid customers only. It’s available now for testing so to give it a try, look for the Tools option when you launch your next test.

You can target a single URL or upload your own Gatling scripts. Here’s an example script to get you started, take note of the additional Gridinit specific variables needed to integrate your results into the Grid. Scenarios need to be labelled with the testguid, the rest are optional parameters to be passed in at runtime saving you the hassle of maintaining multiple scripts.

import com.excilys.ebi.gatling.core.Predef._
import com.excilys.ebi.gatling.http.Predef._
import com.excilys.ebi.gatling.jdbc.Predef._
import com.excilys.ebi.gatling.http.Headers.Names._
import scala.concurrent.duration._
import bootstrap._
import assertions._

class BasicExampleSimulation extends Simulation {

  // Optional, let's you drive a testplan with parameters from our UI
  val threads   = Integer.getInteger("threads", 50)
  val rampup    = Integer.getInteger("rampup", 60).toLong
  val duration  = Integer.getInteger("duration", 60).toLong

  val host      = System.getProperty("host", "altentee.com")
  val port      = Integer.getInteger("port", 80)
  val path      = System.getProperty("path")

  // MANDATORY
  val testguid  = List(System.getProperty("testguid"))

  val httpConf = httpConfig
      .baseURL("http://"+host+":"+port+path)
      .acceptHeader("text/html,application/xhtml+xml,application/xml;")
      .acceptEncodingHeader("gzip, deflate")
      .requestInfoExtractor((request: Request) => { testguid })
      .responseInfoExtractor(response => Option(response.getHeader("Content-Length")).map(List(_)).getOrElse(List("0")))

  val custom_header = Map("User-Agent" -> "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.17 (KHTML, like Gecko) Chrome/24.0.1312.56 Safari/537.17")

  val scn = scenario("my_first_scenario")
      .during(duration seconds) {
        exec(
          http("normal_visit")
            .get("/")
            .headers(custom_header)
            .check(status.is(200)))
        .pause(1000 milliseconds, 5000 milliseconds)
      }

  setUp(scn.users(threads).ramp(rampup).protocolConfig(httpConf))
}

The not too distant future

We still have our eyes on some emerging technology in full browser & mobile automation as do others, particularly with Web Kit based headless browser drivers and various mobile phone emulators. This is an exciting space to be part of and we’ll be looking at more options in the new year.

We’re  still strong advocates of JMeter as we think it’s a great tool for simulating realistic load from a variety of protocols. We’ve already introduced our domain specific language for writing  test plans in Ruby, and we’ll be continuing that work in the new year thanks to the generous feedback and encouragement we’ve received from our users.

We’ll also be expanding our examples and tutorials for different tools including Gatling to let you spend less time scripting, and more time testing!

For more information please contact support@gridinit.com

One thought on “Announcing support for Gatling on the Grid

  1. Pingback: News from the Grid December 2012 « Gridinit

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s