Function Compute:Session affinity: General limitations and principles

1. Limitations specific to Cookie affinity

• Only server-side cookie injection is supported:
  When a client makes its first request, Function Compute automatically injects a cookie into the response using the Set-Cookie header. The client must parse and save this cookie, and include it in subsequent requests.
  
  

• SessionAPI management is supported:
  You can use the SessionAPI for session lifecycle management, such as creating, updating, querying, and terminating sessions.
  
  

2. Limitations specific to HeaderField affinity

• Session ID source:

  • If the client passes a session ID in a predefined header, this value is used as the session identity.

  • If no ID is passed, the server-side generates a globally unique session ID. It is returned in the response header using the header field predefined in CreateFunction.

• Header field definition:
  When you create the function, specify the header field name for transmitting the session ID in SessionAffinityConfig.
  
  

• SessionAPI management is supported:
  You can use the SessionAPI to monitor and control sessions.
  
  

3. Limitations specific to MCP Streamable HTTP affinity

• Protocol version requirements:
  This affinity type supports MCP protocol versions 2025-03-26 and 2025-06-18. The client and function must follow the transport layer specifications of the corresponding version.
  
  

• Compatibility note: If a function has MCP Streamable HTTP affinity enabled, do not use MCP HTTP with Server-Sent Events (SSE) to invoke it. The session management mechanisms are incompatible and will cause invocations to fail.

• Access method limitations:
  Access is supported only through an HTTP trigger or a custom domain name.
  
  

• HTTP trigger configuration requirements:
  The HTTP trigger must support at least the GET, POST, and DELETE methods.
  
  

  Necessity of the DELETE method:
  A client can actively terminate a session by sending a DELETE request. Function Compute then revokes the resources for that session, including the instance concurrency quota. If the DELETE method is not enabled, the system rejects the request, and the session cannot be released properly.
  
  

• SessionAPI management is not supported.

4. Limitations specific to MCP SSE affinity

• Runtime limitations:

  • If you use a built-in runtime, MCP SSE affinity is not supported.

  • If you use an MCP runtime, only MCP affinity (including SSE) is supported.

  • Other runtimes do not have this limitation.

• Client requirements:
  Requests must be initiated using an official MCP standard client or software development kit (SDK). Otherwise, a valid affinity connection cannot be established.
  
  

• Session lifecycle:
  The maximum session lifecycle is equal to the function's maximum timeout period. After this period, the server-side disconnects. Reconnecting generates a new session ID and does not guarantee routing to the original instance.
  
  

• Access method limitations:
  Access is supported only through an HTTP trigger or a custom domain name.
  
  

• Request limitations:

  • The first SSE request does not currently support including query parameters.

  • The maximum concurrency per instance is 200.

• SessionAPI management is not supported.

1. Core flow

Client sends request → Identify/Generate Session ID → Attach to an active instance → Route subsequent requests to that instance

2. Resource model (unified frame)

• Each session consumes one session concurrency quota.

• Each request (including POST, GET, and Message) consumes one request concurrency quota.

• Total concurrency quota per instance: 200 (not adjustable)

• Multiple sessions share this quota of 200.

Formula:

TotalQuota = Σ(Concurrency consumed by each Session) ≤ 200

3. Lifecycle management

Concurrency parameter descriptions

Concurrency resource model for a single session

Configuration recommendations for concurrent sessions per instance:

1. Isolation scenario: Set the value to 1. A single session exclusively uses the computing resources for better security and reliability.

2. Multi-tenant sharing scenario: Set the value to a number in the range (1, 200]. Multiple sessions share the resources of a single instance to improve resource utilization.

Scenario 1: Session and instance binding rules and scale-out mechanism

Assume the function is configured with two concurrent sessions per instance.

1. Client1 sends a request. Instance1 is allocated, consuming one session quota.

2. Client2 sends a request. The scheduler determines that Instance1 has an available session quota and successfully binds the session.

3. Client3 sends a request. Because Instance1 is full, a new instance, Instance2, is created, and the session is successfully bound to it.

Key points:

• The scheduling system tries to reuse existing instances, but this is not guaranteed.

• A scale-out occurs only when all existing instances are full.

• This implements dynamic load balancing and elastic scaling.

Scenario 2: Resource throttling mechanism for multiple sessions on a single instance

Assume the function is configured with two concurrent sessions per instance.

1. Client1 sends a request, which consumes one session quota and one unit of request concurrency.

2. Client2 sends a request, which consumes one session quota and one unit of request concurrency.

3. Before the first two requests are complete, both clients concurrently send another 198 requests, consuming a total of 200 units of request concurrency.

4. The next concurrent request exceeds the limit of 200, and the system returns a `429 Too Many Requests` error.

Key points:

• The maximum concurrency per instance is fixed at 200 and is not adjustable.

• Multiple sessions share this quota.

• When the concurrency quota is exhausted, the system rejects new requests.