jmeter-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oliver Lloyd <>
Subject Websockets
Date Sat, 25 Aug 2012 12:31:46 GMT
Are there any plans to add a new websockets sampler to future releases?

Not a trivial piece of work to be sure, but I really think this transport layer is going to
become very popular, very fast and if this does happen, having support for this protocol would
greatly enhance JMeter's worth. Of course, traditional HTTP isn't going anywhere, but socket
support in browsers is reaching a stable point and there are now several very popular socket-based
frameworks being developed which, when production ready, are going to make this sort of site
much more feasible and and much more common. Check out Meteor, Derby & SocketStream as

I think that to be useful, a sampler should be able to establish a connection, accept (and
validate) messages from the server, and also be able to emit messages to the server. When
sending messages it should be possible to specify a namespace as well as the payload.

The sampler page could define behaviour for a single connection telling JMeter when to send
messages and what to include - this would actually be pretty simple. Response assestions would
act against messages that are received where you would want to be able to specify a different
check based on different nameSpaces / 'rooms'.

Another part of the problem is not just setting up the traffic but also handling how results
are managed. There is no concept of a 'response time' when you broadcast over a socket so
measuring 'performance' would not be done in traditional ways. Also consider that once you
open a TCP connection it stays open so the concept of a 'thread' would morph slightly to become
a 'connection' (one connection = one user).

But I think that you can simplify logging data for this and still have something useful. A
result file might look like:

timeStamp, sessionId*, type, message, nameSpace, 
13nnnnnn, HDGEY45HW8F, SENT, "{myMsg: 'hello'}", "default"
13nnnnnn, HDGEY45HW8F, RECD, "{msg: OK for now}", "status_updates"

(*every socket connection has a session id given to it)

But, really, this data should be stored in json format because in most cases payloads over
websockets are sent as json and, well, also because it's just better.

    timestamp: 13nnnn,
    sessionId: ns4j4,
    type: sent,
    message: "foobar",
    timestamp: 13nnnn,
    sessionId: ns4j4,
    type: sent,
    message: "foobar",
    timestamp: 13nnnn,
    sessionId: H3sFHdSf4HFs54djC,
    type: recd,
    message: {
        part1: "abc".
        part2: "def"                           

You'd obviously also need new listeners for this data - maybe just throughput broken down
by sent / recd plus a new version of the aggregate table.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message