Open ofauchon opened 6 years ago
++ for this!
Always have to resort to the fallback when testing which really isn't testing the right thing.
Long-polling is pain enough to implement in scripts so this is really wanted!
No directions but for the proper (sic!) implementation there are a couple of different Go implementations for the client already. Perhaps you could use one of those as a starting point? Then take a peek at how websockets was implemented in k6 and double up on that?
/Michael
If I understand correctly, Server-Sent Events basically are a simple wrapper around long-lived HTTP requests where the server occasionally pushes data to the client? If so, I think implementing them would be quite difficult with the current synchronous way k6 handles HTTP requests... As @micsjo mentioned, we'd need something like the current way we handle websockets. Maybe even emulate the browser's APIs so we can reuse the work for supporting more browserified libraries...
Hi.
You are right, SSE are long-lived HTTP GET requests. Server periodically use this channel to push datas back to the client.
Why not hacking the http.get(uri,params) to support async calls ? eg: adding extra parameters in 'params' like :
In case async is true, a gorouting/channel would be used in http.go, and GO callback function would call the javascript callback function.
Here is how I imagine it (from Javascript view):
import http from "k6/http";
// HTTP Callback when event / response arrives: export HTTPcallback function(HTTP Response object){
It's a bit more complicated than that. goja (the JS runtime we're using), like most JS runtimes, isn't actually multi-threaded, so some kind of event-loop is necessary to handle asynchronous callbacks. Most calls in k6 are synchronous, but for example for websockets we have a very localized event loop implemented like this.
It's clear for me now. Thanks
BTW - we technically support SSE because it uses plain old HTTP. What happens is k6 only receives the streamed content when the request/response cycle ends, usually as a result of the client-configured timeout (default 60s) elapsing (alternatively, when the server closes the connection). At that point, http.get/post/whatever
will return and yield all of the pushed messages in the response.body
.
If all you need to do is have connections open to the server, and you don't need to "read" any of the data, at least not until the very end of the connection, or when the user-configured client timeout elapses, then you can use k6 for it. Otherwise, you'll need to wait for async support as indicated above.
@mstoykov any news around async support for http
to handle HTTP SSE response?
Hi @JaderCM, there are no specific news. There are internal discussions around different problems that will need to be fixed for the new HTTP API and async APIs in general.
There is no defined estimated time when any of this will land or even if the original new http API will have SSE support or if that will be added later.
I guess someone could try to write an extension support for that, but I am not certain how well that will work :shrug: .
edit: I dropped the js-compat label as this is no longer blocked on js compatibility
no other analogous tool supports SSE and so SSE support would be a stand-out feature for k6
no other analogous tool supports SSE and so SSE support would be a stand-out feature for k6
Depends what you consider an "analogous" tool - Gatling, for instance, has a full support for SSE. I'd love to see SSE support in k6 though.
Hi,
Server-Sent Events (SSE) : a lightweight and standardized technology for pushing notifications from a HTTP server to a HTTP client (One way direction notification).
https://fr.wikipedia.org/wiki/Server-sent_events
I'd like to add SSE support in k6 and I have questions about this task:
Thanks
Olivier