Load Balancing

in uSync, push or pull requests need to go to the same server. Otherwise, requests will fail when they can't find files the previous request left behind. If this happens, you will see a 'file not found' or 'folder missing' error.

tip

If you see a 'File not found' or 'Folder missing' error and you think your site is not load balanced, you should check. It could be load balanced in some way you are not aware of.

uSync has built-in support for keeping a push or pull pinned to one server (server affinity), so this no longer means you have to run the backoffice without load balancing.

Server Affinity

When a target server sets a cookie on its response (an ARR affinity cookie, an Application Gateway cookie, or whatever your load balancer uses) uSync remembers it and sends it back on every later request, keeping everything pinned to the server that answered first.

This setting is on by default and works with any load balancer's affinity cookie. uSync doesn't need to be told the cookie's name.

appsettings.json

{
  "uSync": {
    "Publisher": {
      "Settings": {
        "AffinityEnabled": true,
        "AffinityCookieNames": [],
        "AffinityFailFast": false
      }
    }
  }
}

AffinityEnabled

Turns server-affinity cookie handling on or off. On by default, it only does anything once a target actually sets a cookie, so it's a no-op against a single, non-load-balanced server.

AffinityCookieNames

Cookie names to remember and replay for AffinityEnabled. Empty by default. When empty, replays every cookie the target sets.

AffinityFailFast

Aborts a push or pull the moment requests stop reaching the same target server, instead of letting it continue and fail later with a confusing "missing pack folder" error. Off by default.

A Shared Working Folder

Server affinity keeps requests going to the same server, but the reason it matters is that each server keeps working files on its own local, temporary storage.

If your servers can see shared storage you can point uSync's working folder at it, so every server sees the same files:

appsettings.json

{
  "uSync": {
    "WorkingFolder": {
      "Path": "\\\\shared-server\\usyncwork"
    }
  }
}

Path also accepts a ~/ path relative to your site's content root.

tip

This setting is read once when the site starts. Changing it while the site is running will have no effect until the site is restarted.

Diagnosing An Affinity Issue

Every response from a uSync receive endpoint carries an X-uSync-Node header identifying which server answered it. If a push or pull's requests stop landing on the same server, uSync logs a warning naming the two servers and the step it happened on. Turn on uSync logging to see it.

But This Won't Cover

• The connection between your browser and the source site still needs its own affinity if the source itself is load balanced. This is ordinary load-balancer session affinity, not something uSync configures.
• Progress updates, the live progress bar during a push or pull, use a separate connection that doesn't always follow the same server as the main requests. This only affects how many updates the progress bargives you, never whether the operation itself succeeds. If it becomes a problem, you can turn it off:

appsettings.json

{
  "uSync": {
    "Publisher": {
      "Settings": {
        "ServerToServerHub": false
      }
    }
  }
}

Operations are batched to avoid timeout issues on large site publishing and syncing