Learn the possible WebSocket operations with Gatling: connect, close, send

WebSocket support was initially contributed by Andrew Duffy.

WebSocket support is an extension to the HTTP DSL, whose entry point is the ws(requestName: Expression[String]) method.

WebSocket protocol is very different from the HTTP one as the communication is 2 ways: both client-to-server and server-to-client, so the model is different from the HTTP request/response pair.

As a consequence, the main HTTP branch and a WebSocket branch can exist in a Gatling scenario in a dissociated way, in parallel. When doing so, each flow branch has its own state, so a user might have to reconcile them, for example when capturing data from a WebSocket check and wanting this data to be available to the HTTP branch.

Common operations

If you want to deal with several WebSockets per virtual users, you have to give them a name and pass this name on each ws operation:

wsName(name: String)

For example:

ws("WS Operation").wsName("myCustomName")

If you set an explicit name for the WebSocket, you’ll have to make it explicit for every other WebSocket actions you’ll define later in the scenario.

Of course, this step is not required if you deal with one single WebSocket per virtual user.


The first thing is to connect a WebSocket:

connect(url: Expression[String])

For example:

exec(ws("Connect WS").connect("/room/chat?username=steph"))

You can specify a subprotocol:

exec(ws("Connect WS").connect("/room/chat?username=steph").subprotocol("custom"))

You can define a chain of actions to be performed after (re-)connecting with onConnected:

  ws("Connect WS")
        ws("Perform auth")
          .sendText("Some auth token")


When you’re done with a WebSocket, you can close it:


For example:

exec(ws("Close WS").close)

Send a Message

You may send text or binary messages:

  • sendText(text: Expression[String])
  • sendBytes(bytes: Expression[Array[Byte]])

For example:

    .sendText("""{"text": "Hello, I'm ${id} and this is message ${i}!"}""")

Note that:

  • ElFileBody, PebbleStringBody and PebbleFileBody implement Expression[String] so they can be passed to sendText
  • RawFileBody and ByteArrayBody implement Expression[Array[Byte]] so they can be passed to sendBytes.

See HTTP request body for more information.

Server Messages: Checks

Gatling currently only supports blocking checks that will waiting until receiving expected message or timing out.

Set a Check

You can set a check right after connecting:


Or you can set a check right after sending a message to the server:


You can set multiple checks sequentially. Each one will expect one single frame.

You can configure multiple checks in a single sequence:

// expecting 2 messages
// 1st message will be validated against myCheck1
// 2nd message will be validated against myCheck2
// whole sequence must complete withing 30 seconds
  .await(30.seconds)(myCheck1, myCheck2))

You can also configure multiple check sequences with different timeouts:

// expecting 2 messages
// 1st message will be validated against myCheck1
// 2nd message will be validated against myCheck2
// both sequences must complete withing 15 seconds
// 2nd sequence will start after 1st one completes

Create a check

You can create checks for text and binary frames with checkTextMessage and checkBinaryMessage. You can use almost all the same check criteria as for HTTP requests.

val myCheck = ws
  .check(regex("hello (.*)").saveAs("name"))

You can have multiple criteria for a given message:


checks can be marked as silent. Silent checks won’t be reported whatever their outcome.

  .check(regex("hello (.*)").saveAs("name"))

Matching messages

You can define matching criteria to filter messages you want to check. Matching criterion is a standard check, except it doesn’t take saveAs. Non-matching messages will be ignored.



Websocket support introduces new HttpProtocol parameters:

wsBaseUrl(url: String): similar to standard baseUrl for HTTP, serves as root that will be prepended to all relative WebSocket urls

wsBaseUrls(urls: String*): similar to standard baseUrls for HTTP, serves as round-robin roots that will be prepended to all relative WebSocket urls

wsReconnect: automatically reconnect a WebSocket that would have been closed by someone else than the client.

wsMaxReconnects(max: Int): set a limit on the number of times a WebSocket will be automatically reconnected


In your logback configuration, lower logging level to DEBUG on logger io.gatling.http.action.ws.fsm:

<logger name="io.gatling.http.action.ws.fsm" level="DEBUG" />


Here’s an example that runs against Play 2.2’s chatroom sample (beware that this sample is missing from Play 2.3 and above):

val httpProtocol = http
  .acceptEncodingHeader("gzip, deflate")

val scn = scenario("WebSocket")
  .exec(session => session.set("id", "Steph" + session.userId))
  .exec(ws("Connect WS").connect("/room/chat?username=${id}"))
  .repeat(2, "i") {
    exec(ws("Say Hello WS")
      .sendText("""{"text": "Hello, I'm ${id} and this is message ${i}!"}""")
        ws.checkTextMessage("checkName").check(regex(".*I'm still alive.*"))
  .exec(ws("Close WS").close)

Edit this page on GitHub