1

I've enabled session affinity on Heroku via the CLI - is this enough to make sure traffic from a user hits the same process (Clustering using throng) on the correct dyno (multiple dynos)?

To be clear, I have no code to handle this. I just use socket io as is, I don't use sticky sessions or anything. All I've done is enable session affinity.

Is this enough? How can I test it locally?

Prodigga
  • 1,457
  • 1
  • 22
  • 37
  • Did you get an answer to this one? Do you need to make any changes to your code to make this work? – Avi Dec 16 '19 at 09:35
  • No, I still don't have an answer for this. Seems to be hard to find information for Heroku specific 'advanced' issues. – Prodigga Dec 16 '19 at 23:02

1 Answers1

1

Not sure if you ever got this answered but thinking through this problem myself. Could potentially be enough, however, Socket.io calls out:

"if you are in a CORS situation (the front domain is different from the server domain) and session affinity is achieved with a cookie, you need to allow credentials:"

Source

Given you're using the default long polling then ws connection order, I think Heroku sticky sessions should be able to route your initial long-poll request to the right dyno. The two things I am unclear on:

  1. Once the long-polling request is distributed to the assigned dyno, does the upgrade to websocket connection also connect to the same dyno?
  2. Given that Heroku auto-scaler does not take websocket connections into account (source, search for websocket), how would you auto scale the dynos to account for traffic?

On number 2, it could potentially work via the long-polling API request p95 time being used to determine server load but unsure if API latency would increase due to websocket connections/workload.

Yo_Its_Az
  • 2,043
  • 2
  • 18
  • 25
  • Tried the above steps: enabled "session_affinity" for heroku server, passed credentials via socket.io for CORS handshake, and scaled to 2 dynos. It works... intermittently. Sometimes it works great, connecting with long-polling and upgrading to ws connection. Other times, it gets stuck in a loop polling dyno 1 then 2 without a ws connection upgrade. Curious if anyone else here has solved this issue? – Yo_Its_Az Feb 03 '23 at 23:17
  • Ended up making it work without session affinity by specifying transport as only websocket. The default long polling upgrading to websocket behavior was getting tripped up routing to the same server even with session affinity enabled. Haven't seen any performance hits yet from the direct ws connection. – Yo_Its_Az Feb 06 '23 at 09:35