WS: High CPU usage

[maaft]

I noticed high cpu usage on subscriptions after 30 seconds when no new data comes in. The reason is to be found here:

client/transport/wshandler.go

func (wh *WebsocketHandler) ReadJSON(v interface{}) error {
	ctx, cancel := context.WithTimeout(wh.ctx, wh.timeout)
	defer cancel()
	return wsjson.Read(ctx, wh.Conn, v)
}

When I use no timeout, cpu usage stays low:

func (wh *WebsocketHandler) ReadJSON(v interface{}) error {
	return wsjson.Read(wh.ctx, wh.Conn, v)
}

Not sure if this an issue per se as you can provide your own WebsocketHandler anyways.

[raphaelfff]

Hum, so that timeout is here to accomodate the keepalive, that is supposed to come every X seconds, if it doesnt, we assume the connection is dead, and reset it. I m not a big fan of that solution, feel free to suggest a better implementation!

[maaft]

Ah, interesting. I did not know that this is specified for websockets. Can you point me to any documentation for this?

I'm using two different graphql subscription services and both seem not to send any keepalive messages.

Anyways, a dead connection should not result in high cpu usage.

[raphaelfff]

The apollo implementation does: https://github.com/apollographql/subscriptions-transport-ws (search for keepalive).
Indeed, the current implementation is probably not optimal. Also, since the keepalive is optional, it should be in the client too (which is not currently the case i believe, and that's causing probably your high cpu usage).

IMO the websocket handler should not be responsible for handling the timeout, but rather the reading should be canceled by the client if the keepalive timeout is exceeded I actually have mixed feelings about this one

[raphaelfff]

@maaft Could you give a try to whatever is on master right now ? in your case passing 0 for the timeout should work well