5 ms·

Heroku WebSocket performance

66 points by hassy 13y ago

bytasv 13y ago
It would be really interesting to see the same test done with 2 and then maybe 3 dynos running. I'm wondering how well would that scale with more dynos running. Is it possible to buy dynos for shorter time than a month?
thatthatis 13y ago
How does 160 connection per dyno compare to comparably priced servers elsewhere?
- _neil 13y ago
  That's per dyno, per second. 6,000 per dyno total, which seems very reasonable. As timdorr mentioned, Pusher's largest (publicly available?) plan only allows for 5,000 connections.
- hassy 13y ago
  I ran a quick test, an entry-level box from Digital Ocean can sustain 350+ connections/sec and maxes out at around 7,200 open connections. Having root access to the machine would allow you to optimise some things and probably raise those numbers, but then you don't get the convenience of using Heroku.
- bradgessler 13y ago
  We run http://firehose.io/ http://firehose.io/ on smaller SoftLayer metal servers and get around 10k connections per box. These servers cost $250 per month, so we get about 20k connections for $500 per month. By my back of napkin numbers Heroku is about 10x the cost of real metal servers.
buster 13y ago
Wow.. 160 connections per second sounds really slow.. is a dyno such a small unit? Never worked with Heruko..
- timdorr 13y ago
  These are WebSockets, not typical HTTP requests. Connections/sec is less important because they will be long-running. The client is not continually reconnecting as they do with an HTTP request. What matters most is total connection count, which appears to be very high. At 6,000 open connections on a free dyno, that is better than Pusher's $199/mo plan: http://pusher.com/pricing http://pusher.com/pricing I think what needs to be done after this is checking how much data can be sent per second. Both in terms of raw bandwidth and messages/sec.
  - GrinningFool 13y ago
    Does pusher also work by holding open connections? If so, it seems that neither option is very respectful of mobile users' battery life...
    - m0th87 13y ago
      Obviously take this with a grain of salt since I didn't publish anything, but When I did some analysis on battery life impact of HTTP polling vs websockets two years ago, the difference was completely negligible compared to keeping the screen on (which I had to do for the analysis) on the iPhone 4. This makes sense in retrospect, but it appears as if websockets don't have a huge impact.
    - djb_hackernews 13y ago
      What is it about an open connection that would drain the battery? It's not like it has to consume a thread in a busy wait.
    - beaumartinez 13y ago
      Correct me if I'm wrong, but isn't the point of web sockets a persistent connection to the server, to facilitate sending updates? You assume the battery life hit in using them. It'd be interesting to see the trade-offs between web sockets and persistent polling.
      - 13y ago
slig 13y ago
Does anyone know if the free Dyno is always running or it's started once there's a request and killed after a timeout? I couldn't find this info in the pricing page.
- derekchiang 13y ago
  Yeah, it's killed after a timeout and restarted when a new request comes in. Which is why when you revisit an old Heroku app it takes a long time to load.
- ksylvest 13y ago
  You can keep a single free Dyno "awake" by hitting it with a request at least once per hour. If you use New Relic the built in availability monitoring will do the trick and otherwise Scheduler should work. For more info: https://devcenter.heroku.com/articles/dynos#dyno-idling https://devcenter.heroku.com/articles/dynos#dyno-idling
  - felipesabino 13y ago
    Now you can also check if your app is sleeping on the dashboard :) https://blog.heroku.com/archives/2013/6/20/app_sleeping_on_heroku https://blog.heroku.com/archives/2013/6/20/app_sleeping_on_h... Also, I used pingdom.com once to make sure that my "very low in traffic" app never sleeps, but any solution that performs a request in this interval would be valid
- rdegges 13y ago
  Correct. If you're running more than one dyno in an app, however, there are no 'timeouts'. If you're trying to maximize your free dyno usage, however, you might want to use the 'heroku scheduler' addon, and have it ping your app once every 10 minutes to keep it 'awake'.
swaagie 13y ago
You might want to check out https://github.com/observing/thor https://github.com/observing/thor, it's basically wrk/ab for sockets.

66 points by hassy 13y ago

It would be really interesting to see the same test done with 2 and then maybe 3 dynos running. I'm wondering how well would that scale with more dynos running. Is it possible to buy dynos for shorter time than a month?

thatthatis 13y ago

How does 160 connection per dyno compare to comparably priced servers elsewhere?

_neil 13y ago
That's per dyno, per second. 6,000 per dyno total, which seems very reasonable. As timdorr mentioned, Pusher's largest (publicly available?) plan only allows for 5,000 connections.
hassy 13y ago
I ran a quick test, an entry-level box from Digital Ocean can sustain 350+ connections/sec and maxes out at around 7,200 open connections. Having root access to the machine would allow you to optimise some things and probably raise those numbers, but then you don't get the convenience of using Heroku.
bradgessler 13y ago
We run http://firehose.io/ http://firehose.io/ on smaller SoftLayer metal servers and get around 10k connections per box. These servers cost $250 per month, so we get about 20k connections for $500 per month. By my back of napkin numbers Heroku is about 10x the cost of real metal servers.

buster 13y ago

Wow.. 160 connections per second sounds really slow.. is a dyno such a small unit? Never worked with Heruko..

timdorr 13y ago
These are WebSockets, not typical HTTP requests. Connections/sec is less important because they will be long-running. The client is not continually reconnecting as they do with an HTTP request. What matters most is total connection count, which appears to be very high. At 6,000 open connections on a free dyno, that is better than Pusher's $199/mo plan: http://pusher.com/pricing http://pusher.com/pricing I think what needs to be done after this is checking how much data can be sent per second. Both in terms of raw bandwidth and messages/sec.
- GrinningFool 13y ago
  Does pusher also work by holding open connections? If so, it seems that neither option is very respectful of mobile users' battery life...
  - m0th87 13y ago
    Obviously take this with a grain of salt since I didn't publish anything, but When I did some analysis on battery life impact of HTTP polling vs websockets two years ago, the difference was completely negligible compared to keeping the screen on (which I had to do for the analysis) on the iPhone 4. This makes sense in retrospect, but it appears as if websockets don't have a huge impact.
  - djb_hackernews 13y ago
    What is it about an open connection that would drain the battery? It's not like it has to consume a thread in a busy wait.
  - beaumartinez 13y ago
    Correct me if I'm wrong, but isn't the point of web sockets a persistent connection to the server, to facilitate sending updates? You assume the battery life hit in using them. It'd be interesting to see the trade-offs between web sockets and persistent polling.
    - 13y ago

slig 13y ago

Does anyone know if the free Dyno is always running or it's started once there's a request and killed after a timeout? I couldn't find this info in the pricing page.

derekchiang 13y ago
Yeah, it's killed after a timeout and restarted when a new request comes in. Which is why when you revisit an old Heroku app it takes a long time to load.
ksylvest 13y ago
You can keep a single free Dyno "awake" by hitting it with a request at least once per hour. If you use New Relic the built in availability monitoring will do the trick and otherwise Scheduler should work. For more info: https://devcenter.heroku.com/articles/dynos#dyno-idling https://devcenter.heroku.com/articles/dynos#dyno-idling
- felipesabino 13y ago
  Now you can also check if your app is sleeping on the dashboard :) https://blog.heroku.com/archives/2013/6/20/app_sleeping_on_heroku https://blog.heroku.com/archives/2013/6/20/app_sleeping_on_h... Also, I used pingdom.com once to make sure that my "very low in traffic" app never sleeps, but any solution that performs a request in this interval would be valid
rdegges 13y ago
Correct. If you're running more than one dyno in an app, however, there are no 'timeouts'. If you're trying to maximize your free dyno usage, however, you might want to use the 'heroku scheduler' addon, and have it ping your app once every 10 minutes to keep it 'awake'.

swaagie 13y ago

You might want to check out https://github.com/observing/thor https://github.com/observing/thor, it's basically wrk/ab for sockets.