-
Notifications
You must be signed in to change notification settings - Fork 93
Affinitization: benefits, drawbacks, how to
Affinitization is when your requests are allocated to a specific Bungie.net server for all of your subsequent requests. Depending on your app, you may or may not want to affinitize.
Affinity is set by honoring and passing the sto-id-sg_live.bungie.net cookie in subsequent requests, which gets set as a set-cookie header in the response to any request to the server that doesn't have the cookie already set.
Affinitization is useful when your app is a single user app that provides rich interaction. If you're affinitized to a single server for - say - an Item Management app, then performing actions on items will properly bust the cache and show you the latest state of the user on subsequent requests.
In this situation, since the app is for a single user - and thus making requests on behalf of that single user for any given instance of the app - you're also making sure that your overall workload is still spread out across all of our servers (as one user with your app may be affinitized to a different server than another user with a separate instance of your app), which makes you a good citizen and less likely for us to have to block your access or throttle you.
If you're filtering requests through a proxy server, you may/will want to set up your connections to the API such that each user of your app has its own affinitization cookie stored and ready for use to retain the benefits of per-user affinitization mentioned above. I would not recommend affinitizing to the same server for all user's requests: that will put an undue burden on our servers, and may result in your service being throttled or blocked.
If your app is performing a large number of bulk actions, or if it is not interactive (performing write actions along with read actions), you will gain no real benefits from affinitization: you're only setting yourself up for potential problems as all of your requests will go to a single Bungie.net server, which could result in your requests being throttled or blocked entirely.
In these situations, I highly recommend you ignore the set-cookie header for the sto-id-sg_live.bungie.net cookie, and don't pass it in subsequent requests. Doing this will keep your requests non-affinitized, and will spread your requests out to multiple BNet servers.
In an ideal world, we'd have a setting in the Application Settings page that would let you choose the type of app you're using and send/not send this affinitization cookie based on your type of application... but as it is, I don't think we're going to have time to implement that. Therefore, if you want to maximize your throughput to the API and minimize your chance of being throttled or blocked while maximizing your interactivity, it'll be up to you to follow the guidelines listed above!
It will depend on the library you're using for your HTTP requests. Consult its documentation about how your library handles cookies. It may provide functionality to let you ignore set-cookie headers in the response, to not pass cookies at all, or to remove cookies that have been set before making subsequent requests.