Is this the same as the http4s version? why the "concurrently"?

second question: isn't IO.realTime "slow" by itself, esp when called under stress? For better isolation of the purely WS performance, would it make a difference if we just returned IO.pure(1823)?

This has been entirely copied from https://github.com/kamilkloch/websocket-benchmark/

Is this the same as the http4s version? why the "concurrently"?

The behavior of the stream should be the same. Vanilla implementation requires a send: Stream[F, WebSocketFrame] and a receive: Pipe[F, WebSocketFrame, Unit].
The Tapir logic has to return a Stream[F, Long] based on an input Stream so maybe it needs this additional concurrently operator to correctly make the result stream "run after the input stream is read".
I wanted to keep the implementation 1:1 with the base benchmark for a start.

second question

The returned timestamp is used to calculate latency on the client. I found that suspicious too, but if Kamil's tests result in latencies of a few milliseconds, then it might not be that expensive after all.

ok, so we ignore the input, and as the output produce timestamps. But how do we calculate the latency from that? The scenario reads a single message, compares timestamps and waits for a second, right? But isn't that skewed by any delay that there might be when establishing the web socket, that is, this assumes that the WS sends its timestamp, and that the scenario ends its sleep at exactly the same time (to properly measure latency)

My understanding is that the server returns its timestamp after the connection is established, so the client receives it immediately and compares to its timestamp. The await call is unclear to me, maybe it only means to await at most, but I need to double check.

I found this example in Gatling docs:

// expecting 2 messages
// 1st message will be validated against wsCheck1
// 2nd message will be validated against wsCheck2
// whole sequence must complete withing 30 seconds
exec(ws("Send").sendText("hello")
  .await(30)(wsCheck1, wsCheck2))

It confirms what I suggested, that the await(1.second) operator means only that the response check has to complete in 1 second.

ah ok ... so we want to measure the total latency of: establish a ws connection, send one message, receive one message? Why not simply doing it on the client side, capturing the timestamp, doing the operations, and then getting the local timestamp again?

The connection part is not measured. After connecting, the client sends requests and does the checks in a loop. It looks the intention was to measure only the latency of one direction: not full req->response cycle, but just the server->client part.

As far as I understand the response stream, it emits a timestamp every 100 ms. It looks like we're simply ignoring requests, just emitting timestamp every 100ms and measuring the time between sending it and receiving on the client side.

I guess this entire scheme may be caused by Gatling's communication model, where you can't simply connect and receive messages, you have to send a request and receive a response, but the test is interested only in the response generated -> response received part, and the responses are generated in an independent stream.

pin in steward's config?

It's pinned, but I pinned it after steward had updated it.

ah now it's clear, thanks :)