Manual Chapter : Accelerating Parallel HTTP Requests

Applies To:

Show Versions Show Versions

BIG-IP AAM

  • 14.1.3, 13.1.5, 13.1.4, 13.1.3, 13.1.1, 13.1.0, 13.0.1, 13.0.0

BIG-IP APM

  • 14.1.3, 14.1.2, 14.0.1, 14.0.0, 13.1.5, 13.1.4, 13.1.3, 13.1.1, 13.1.0, 13.0.1, 13.0.0
Manual Chapter

Overview: HTTP request queuing

You can use the BIG-IP® system to accelerate responses and reduce the number of requests sent to origin web servers, freeing them to perform other tasks, by queuing HTTP requests. HTTP request queuing provides the ability to queue a large number of parallel HTTP requests for the same object, and provide a cached response to those requests, resulting in accelerated responses from the BIG-IP system and a reduction in requests sent to origin web servers.

The BIG-IP system manages the queued HTTP requests in accordance with the cache status of the requested object, that is, whether the requested object is uncached, cached and valid, cached and expired, uncacheable, or nonexistent.

Object cache status Description
Initial requests for an uncached object When the BIG-IP system receives a large number of parallel requests for an object that is not yet cached, it queues the requests, and then sends one of the requests to an origin web server. When the BIG-IP system receives the first response, it determines whether the response is cacheable while sending the response to the client. If the response is cacheable, the BIG-IP system sends a second request to the origin web server, caches the response with the object, and uses that cached response to service the queued requests.
Requests for a cached object When the BIG-IP system receives a large number of parallel requests for a valid cached object, it services the requests with the cached response.
Requests for an expired cached object If a cached object is expired, instead of sending all requests to the origin web server, the BIG-IP system queues the requests, and then sends one request to an origin web server for fresh content. When the BIG-IP system receives the fresh response, it caches the response with the fresh content, and uses the cached response to service the queued requests.
Requests for an invalidated cached object If a cached object requires validation, the BIG-IP system can queue the requests, and then send one request to an origin web server for fresh content. When the response is received, the BIG-IP system caches the response with the fresh content, and uses the cached response to service the queued requests.
Requests for an uncacheable object Sometimes, an object cannot be cached, for example, if the object exceeds the maximum object size or if the response includes a no-store response header. When the BIG-IP system first receives a large number of parallel requests for an object that cannot be cached, instead of sending each request to an origin web server, the BIG-IP system queues the requests, and then sends one request to an origin web server. When the BIG-IP system receives the response, it sends the queued requests to the origin web server. Subsequent requests for the uncacheable object bypass the BIG-IP system and are sent directly to the origin web server.
Requests for a nonexistent object When the BIG-IP system receives a large number of parallel requests for an object that does not exist or no longer exists, the BIG-IP system can queue the requests, and then send one request to an origin web server. When the BIG-IP system receives the response with a 404 (Not Found) status code, it services the queued requests with the 404 (Not Found) response. Note that the 404 (Not Found) response is not cached, and all subsequent requests for the nonexistent object are sent to the origin web server.

Enabling HTTP request queuing

You can queue parallel HTTP requests for the same object, and provide a cached response to those requests, resulting in accelerated responses from the BIG-IP and a reduction in requests sent to origin web servers.
  1. On the Main tab, click Acceleration > Web Application > Policies .
    The Policies screen displays a list of existing acceleration policies.
  2. Click the name of a user-defined acceleration policy.
  3. Click a node in the Policy Tree.
  4. From the Matching Rules menu, choose Acceleration Rules.
  5. On the menu bar, click Responses Cached.
  6. Select the Queue Parallel Requests check box.
    Important: The Cache content on first hit check box must be clear to enable the Queue Parallel Requests setting. If the Cache content on first hit check box is selected, the Queue Parallel Requests setting is disabled.
  7. Optional: For the Object Min Size setting, clear the Use Profile Setting check box, and type the minimum object size (in bytes) to cache, overriding the Web Acceleration profile setting.
  8. Optional: For the Object Max Size setting, clear the Use Profile Setting check box, and type the maximum object size (in bytes) to cache, overriding the Web Acceleration profile setting.
  9. Click Save.
  10. Publish the acceleration policy.
    1. Click Publish.
    2. In the Comment field, type a description.
    3. Click Publish Now.
The BIG-IP policy is enabled to queue concurrent HTTP requests for an object, cache a response, and provide the cached response to the queued requests.

Disabling HTTP request queuing

You can disable HTTP request queuing for an object, sending all requests for an object to the origin web servers or using the cached responses, as applicable.
  1. On the Main tab, click Acceleration > Web Application > Policies .
    The Policies screen displays a list of existing acceleration policies.
  2. Click the name of a user-defined acceleration policy.
  3. Click a node in the Policy Tree.
  4. From the Matching Rules menu, choose Acceleration Rules.
  5. On the menu bar, click Responses Cached.
  6. Clear the Queue Parallel Requests check box.
  7. Click Save.
  8. Publish the acceleration policy.
    1. Click Publish.
    2. In the Comment field, type a description.
    3. Click Publish Now.
HTTP request queuing for an object is disabled.