HeaderField affinity in Function Compute routes requests to specific instances using a client session identity from the request header. Function Compute creates a hash of this identity to ensure that all requests with the same identity are routed to the same instance.
How it works
HeaderField session lifecycle
Function Compute uses a dual-threshold mechanism for the HeaderField session lifecycle. A session expires if either of the following conditions is met:
Session lifecycle: The total time from when a session is created until it is destroyed. If a session exceeds its configured lifecycle duration, Function Compute automatically destroys the session. Affinity is no longer guaranteed.
Session idle time: The period during which a session is inactive. If a session remains idle for a specified duration, it expires. The maximum idle time cannot exceed the session's total lifecycle duration.
You can configure appropriate values for your scenario:
Continuously active: Frequent requests reset the idle timer, which prevents the session from being revoked due to inactivity.
Idle revocation: The session is revoked if the interval between requests exceeds the configured idle timeout.
Forced revocation: The session is revoked if the instance's time to live exceeds the session's maximum lifecycle duration.
Session concurrency management
You can configure limits as needed for your scenario:
In non-affinity mode, you can adjust the per-instance concurrency.
In affinity mode, you can only limit the maximum number of concurrent sessions per instance. The maximum number of concurrent requests for all sessions on a single instance is 200.
Concurrency parameter type | Description | Adjustable | Limit | Consumption rule | Concurrency release mechanism |
Maximum concurrency per instance | The maximum number of concurrent requests that a single instance can process simultaneously. Requests that exceed this limit are routed to other instances or are rejected due to throttling. | Not adjustable | 200 | Each request consumes one concurrent slot. | Released asynchronously after the request is processed. |
Concurrent sessions per instance | The maximum number of sessions that a single instance can process at the same time. Requests from multiple sessions share the 200 concurrent request limit. | Adjustable | [1, 200] | Each HeaderField value consumes one session slot for its entire lifecycle. | Released after the HeaderField expires. |
Expected behavior for session affinity (instance scheduling rules)
Scenario 1: Session-to-instance attachment and session-triggered scale-out
Function Compute uses a policy that limits the number of concurrent sessions per instance. Each instance can have a maximum of n sessions attached. The process is as follows:
Assume a function is configured to allow two attached sessions. When Client1 sends a request with a new header, Instance1 is allocated and uses one concurrent session slot.
When Client2 sends a request with a new header, the scheduler determines that Instance1 has an available session slot. The session is then attached to Instance1.
When Client3 sends a request with a new header, the scheduler finds that both concurrent session slots on Instance1 are occupied, so a new session cannot be attached. The request is then scheduled to a new instance, Instance2, and a session is attached to it.
Scenario 2: Throttling for multiple sessions on a single instance
Assume a function is configured to allow two concurrent sessions. When Client1 sends its first request with HeaderA, Instance1 is allocated. The instance uses
1 concurrent session slot + 1 concurrent request slot.When Client2 sends its first request with HeaderB, the scheduler finds that Instance1 has an available concurrent session slot. The new session is attached to Instance1. The instance now uses
2 concurrent session slots + 2 concurrent request slots.Client1 and Client2 then send 198 more concurrent requests using their respective headers. The instance now uses
2 concurrent session slots + 200 concurrent request slots.When another request arrives, the instance's limit of 200 concurrent requests is reached. The request is throttled, and a 429 error is returned.
Smooth function updates
In a HeaderField affinity scenario, requests are stateful at the session level rather than at the request level. After a function is updated, requests with existing HeaderField values are still routed to their original instances. Requests with new HeaderField values are routed to new instances created after the update. This process is shown in the following figure.
Smooth transition
When you update a function, Function Compute ensures a smooth transition by automatically running two versions of the function concurrently.
Requests with existing HeaderField values: Requests with an existing header, such as HeaderA, are automatically routed to the original V1 instances.
Requests with new HeaderField values: New requests, such as those with HeaderB, are attached to newly created V2 instances.
When instances are destroyed
Original V1 instances: Each request resets the instance's idle timer. The instance is revoked if either of the following conditions is met:
The period of inactivity is greater than `idleTimeout`.
The instance's time to live is greater than `sessionTTL`.
New V2 instances: These instances are revoked based on the same rules as the V1 instances.
Billing
Session affinity costs = Cost of active elastic instances processing requests + Cost of idle elastic instances during the keepalive period
For more information about how costs are calculated for active and idle elastic instances, see Billing overview.