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 examples.
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",
etc...
},{
timestamp: 13nnnn,
sessionId: ns4j4,
type: sent,
message: "foobar",
etc...
},{
timestamp: 13nnnn,
sessionId: H3sFHdSf4HFs54djC,
type: recd,
message: {
part1: "abc".
part2: "def"
},
etc...
}]
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.
Oliver
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
