Show HN: Realtime Server-Sent Events in Go

http://sse.getgin.io

by manucorporat • 11 years ago

118 37 11 years ago

sse.getgin.io

rememberlenny• 11 years ago

Seems pretty solid. Folds after 4k requests a second when tested using:

```

var int = 1;

window.setInterval(function(){

int = int + 1; var data = { message: "test " + int, nick: "rl" };

$.ajax({ type: "POST", url: "http://sse.getgin.io/room-post/hn?nick=rl", data: data, });

}, 5);

manucorporat4• 11 years ago

it uses a 2 cores machine.

jeromenerf• 11 years ago

Yeah, your precious benchmark was well appreciated by the folks on the HN "room". Thank you.

aikah• 11 years ago

You sir made my browser crash.

artursapek• 11 years ago

lmfao

fixxer• 11 years ago

we noticed

tunesmith3• 11 years ago

Anyone want to take a stab on exactly what happened that made this test crash it? 4k requests / second would mean that if you had 100 people connected, it would spawn 400,000 outbound messages per second on the server side, or 4,000 for each user. That wouldn't overwhelm an http connection limit but I guess it would overwhelm the processors on the server side. Plus perhaps make some browsers crash from JS trying to process so much incoming information without disconnecting.

wyc• 11 years ago

Cool! I love net/http.

Below is my stab from a while ago. It's more of an example than a library.

https://github.com/wyc/go-server-sent-events-example/blob/ma...

I think it's great that the language makes the implementations so similar.

andrewstuart22• 11 years ago

SSE is awesome, and Gin seems to have a nice implementation. I definitely like the usage for realtime streaming stats since that's a one-way stream.

Chat, however, would be better served with websockets. If it's bidirectional, use websockets and avoid both upstream and downstream cost of setting up a connection.

SSE works, but you should consider it tech debt if you decide to go that way.

</psa>

jkarneges2• 11 years ago

WebSockets will definitely provide the lowest latency for client->server transmission, but calling SSE "technical debt" for a chat service is a bit harsh. Many chat services get by just fine with HTTP POST for message submission. It's a case of trading low latency for simpler tooling.

Here's a recent article about Secret using POST for sending: https://medium.com/@davidbyttow/scaling-secret-real-time-cha...

andrewstuart22• 11 years ago

It's not so much latency to me. It's the waste. There's both extra latency and extra byte overhead. It's a trivial implementation difference (in all the frameworks I'm familiar with) and as developers, I think we have a responsibility to be efficient and not waste energy and bandwidth.

At scale, you might be talking hundreds or even thousands more clients per server (depending on the server size). On mobile, you use less data which fires up the radio less which directly translates to battery life.

Assuming that your application gets any sort of traction, the 30 minutes of dev time you saved may have a much higher net impact on the world purely by the multiplicative effect. When your product affects that many people, you should remember that you have a responsibility to be sustainable.

krisdol• 11 years ago

Nice. It didn't like <> as a username, however. The chat will no longer load.

jweir• 11 years ago

If you are interested `eventsource` is a Server-sent event library that ties into the Go std http library.

https://github.com/antage/eventsource

fweespeech2• 11 years ago

SSE is awesome...except for the fact that IE has 0% support and is too popular to ignore.

It is a very pretty demo tho, well done :)

qubyte4• 11 years ago

SSE is easy to shim! We use: https://github.com/Yaffle/EventSource/

supermatt2• 11 years ago

Sadly these shims require a per-client queue to ensure message delivery, as events will otherwise be lost during reconnections.

fweespeech2• 11 years ago

That looks like a very high quality shim, so that is good.

However, why would I want to use a shim over websockets?

http://caniuse.com/#feat=websockets

manucorporat4• 11 years ago

IP blocking running. It is a Gin middleware for rate limiting.

carbocation• 11 years ago

It doesn't seem to be doing a great job. User "hello" keeps sending several thousand message bursts. On the flip side, the rest of the backend seems to be doing a fantastic job handling the bursts.

manucorporat4• 11 years ago

yeah! it took me some time to get it right. I did not planned it well.

ohitsdom• 11 years ago

Awesome demo, although the troll comments are obnoxious. But I guess they're doing their part in showing off the "realtime" nature of the demo.

tunesmith3• 11 years ago

I'm curious what the bounds are on the client-side use case. For instance, machines can handle tons of simultaneous http connections, but it's easier to reach that limit if you hold SSE connections open for a while.

I've used SSE in the context where we sent chunked pages of one output stream (where the stream was generated server-side all at once), but not where the connection is opened and then actually waiting for additional server information. Is it common for SSE connections to be held open for 30 seconds or even several minutes to be able to stream information?

namelezz• 11 years ago

SSE lets you keep the connection as long as you want. I am not sure what you mean by client-side. If you mean Web Browser then I believe there is certain limit of parallel HTTP connections that you can have depending on the browser. http://stackoverflow.com/questions/985431/max-parallel-http-....

qubyte4• 11 years ago

The issue with maximum open connections will go away with HTTP/2, and you can get around it today using SPDY since both multiplex connections to a domain.

tunesmith3• 11 years ago

I'm more wondering about the number of open HTTP connections that a server can support. Googling around, I see mentions of 64,000 for vanilla servers, perhaps millions depending on the server (affected by # of processor...?)

So if your SSE connection is 10 minutes long and you might have more than 64,000 simultaneous connections to your vanilla box in those 10 minutes, you just need to start load-balancing I guess.

bjt• 11 years ago

Both Chrome and Firefox limit you to 6 simultaneous http connections to the same host. Try opening this app in 7 separate tabs, and you'll see the 7th one just spin and not even load the page's HTML.

At least in Firefox, the limit for websockets is much more generous (200, but shared across the whole browser, IIRC).

Both the Chrome and Firefox dev teams WONTFIXed my suggestion to increase the limit for Server Sent Event connections.

https://code.google.com/p/chromium/issues/detail?id=275955

https://bugzilla.mozilla.org/show_bug.cgi?id=906896

manucorporat4• 11 years ago

It is stable now. I will post my thoughts after the storm. Now I am too busy managing the threats.

late2part• 11 years ago

This is beautifully done, and simple and effective. Great demo page!!

JustSomeNobody• 11 years ago

Cool and all, but I really wish there was a better word than "realtime". I dislike when we hijack a word that already has a meaningful use.

JulienSchmidt• 11 years ago

Gives me opportunity to showcase a tiny app I made for Christmas to remotely present photos over the web using SSE and Go: https://github.com/julienschmidt/remotephotoshow

It doesn't use Gin, but httprouter, which is also the basis for Gin.

fit2rule• 11 years ago

Neat .. is it supposed to show next/previous photo's in the slideshow, though? Because that doesn't seem to be working for me.

Thanks for providing the link - I'll definitely learn me some httprouter soon ..

Show HN: Realtime Server-Sent Events in Go

Related Stories