6 ms·
Show HN: Realtime Server-Sent Events in Go
- rememberlenny 11y agoSeems 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" http://sse.getgin.io/room-post/hn?nick=rl", data: data, }); }, 5);
- manucorporat 11y agoit uses a 2 cores machine.
- jeromenerf 11y agoYeah, your precious benchmark was well appreciated by the folks on the HN "room". Thank you.
- aikah 11y agoYou sir made my browser crash.
- artursapek 11y agolmfao
- fixxer 11y agowe noticed
- tunesmith 11y agoAnyone 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 11y agoCool! 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/master/server_sent_events.go https://github.com/wyc/go-server-sent-events-example/blob/ma... I think it's great that the language makes the implementations so similar.
- andrewstuart2 11y agoSSE 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>
- jkarneges 11y agoWebSockets 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-chat-d8589f8f0c9b https://medium.com/@davidbyttow/scaling-secret-real-time-cha...
- andrewstuart2 11y agoIt'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 11y agoNice. It didn't like <> as a username, however. The chat will no longer load.
- jweir 11y agoIf you are interested `eventsource` is a Server-sent event library that ties into the Go std http library. https://github.com/antage/eventsource https://github.com/antage/eventsource
- fweespeech 11y agoSSE 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 :)
- qubyte 11y agoSSE is easy to shim! We use: https://github.com/Yaffle/EventSource/ https://github.com/Yaffle/EventSource/
- supermatt 11y agoSadly these shims require a per-client queue to ensure message delivery, as events will otherwise be lost during reconnections.
- qubyte 11y agoI'm not sure I'm following you. How does this differ from native EventSource?
- supermatt 11y agoEventSource sends all events over a single connection which it keeps open indefinitely. This shim receives a single event and then reconnects. In that window there is a period where there will be no connection to send events over, so they will be lost without a queue. Edit: actually this looks to be a lot more sophisticated than the other shims i havr looked at and does indeed behave more like eventsource. Good job!
- qubyte 11y agoAh, you're suggesting that the shims use long-polling. I don't think that's the case though. If I understand the library correctly, it really is keeping a connection open, so it's really very similar to the way EventSource works. Addition: Verified. It doesn't disconnect between events (not long-polling).
- deleted 11y ago
- manucorporat 11y agoIP blocking running. It is a Gin middleware for rate limiting.
- carbocation 11y agoIt 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.
- manucorporat 11y agoyeah! it took me some time to get it right. I did not planned it well.
- ohitsdom 11y agoAwesome demo, although the troll comments are obnoxious. But I guess they're doing their part in showing off the "realtime" nature of the demo.
- tunesmith 11y agoI'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 11y agoSSE 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-connections-in-a-browser http://stackoverflow.com/questions/985431/max-parallel-http-....
- qubyte 11y agoThe 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.
- tunesmith 11y agoI'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.
- jkarneges 11y agoThere's a common misconception about the number of TCP connections a server can handle being limited by the number of local ports (~64K). The real limit is in the number of LocalIP+LocalPort+RemoteIP+RemotePort pairs. If your traffic is coming from arbitrary Internet addresses, then you are not limited by ports. Of course you'll be limited by other factors such as kernel fd limits (which are adjustable) and the CPU needed to monitor lots of sockets.
- manucorporat 11y agoIt is stable now. I will post my thoughts after the storm. Now I am too busy managing the threats.
- late2part 11y agoThis is beautifully done, and simple and effective. Great demo page!!
- JustSomeNobody 11y agoCool 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 11y agoGives 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 https://github.com/julienschmidt/remotephotoshow It doesn't use Gin, but httprouter, which is also the basis for Gin.
- fit2rule 11y agoNeat .. 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 ..