Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

HTTP SSE (Server-Sent Event) support for k6 #746

Open
ofauchon opened this issue Aug 18, 2018 · 11 comments
Open

HTTP SSE (Server-Sent Event) support for k6 #746

ofauchon opened this issue Aug 18, 2018 · 11 comments
Labels
feature new-http issues that would require (or benefit from) a new HTTP API

Comments

@ofauchon
Copy link
Contributor

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:

  • Anyone already working on this feature ?
  • Any directions for the implementation ?

Thanks

Olivier

@micsjo
Copy link
Contributor

micsjo commented Aug 19, 2018

++ 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

@na-- na-- added the feature label Aug 20, 2018
@na--
Copy link
Member

na-- commented Aug 20, 2018

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...

@na-- na-- added the js-compat label Aug 20, 2018
@ofauchon
Copy link
Contributor Author

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 :

  • async => True/False
  • callback => Callback function when response arrives.

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):

test.js

import http from "k6/http";

// HTTP Callback when event / response arrives:
export HTTPcallback function(HTTP Response object){

}

export default function() {
let params = { async: true, callback: httpresponse,};
let res = http.get("https://loadimpact.com", params);
};

But I dont' know if .js callback functions can be called from .go http callback.

This way, we could reuse existing http module, and have generic HTTP asynchronous
mecanisms that can be used above the SSE scope.

Olivier

@na--
Copy link
Member

na-- commented Aug 20, 2018

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.

@ofauchon
Copy link
Contributor Author

It's clear for me now.
Thanks

@tom-miseur
Copy link

tom-miseur commented Jun 17, 2021

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.

@na-- na-- added the new-http issues that would require (or benefit from) a new HTTP API label Oct 18, 2021
@JaderCM
Copy link

JaderCM commented Oct 21, 2022

@mstoykov any news around async support for http to handle HTTP SSE response?

@mstoykov
Copy link
Contributor

mstoykov commented Nov 16, 2022

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 🤷 .

edit: I dropped the js-compat label as this is no longer blocked on js compatibility

@iambumblehead
Copy link

no other analogous tool supports SSE and so SSE support would be a stand-out feature for k6

@Fossan
Copy link

Fossan commented Jul 19, 2023

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.

phymbert added a commit to phymbert/k6 that referenced this issue Mar 13, 2024
phymbert added a commit to phymbert/k6 that referenced this issue Mar 13, 2024
@phymbert
Copy link

phymbert commented Apr 4, 2024

If you are looking for the SSE support in k6, please give a try to the xk6-sse community extension.

@github-actions github-actions bot added the triage label Apr 4, 2024
@joanlopez joanlopez removed their assignment Apr 5, 2024
@oleiade oleiade removed the triage label Sep 5, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature new-http issues that would require (or benefit from) a new HTTP API
Projects
None yet
Development

Successfully merging a pull request may close this issue.