Application Accelerator

A cache files each stored response under a key built from the request. When that key holds only the URL, every request for the URL receives the same copy. That copy is wrong for content that changes with a cookie, a device, or an argument. Adding that input to the key gives each of its values a copy of its own. One URL then holds several correct responses, and no visitor receives the response meant for another.

Application Accelerator puts those inputs into the cache key on an application: a query-string argument, a cookie, the device group, or the request method. Its switch in Main Settings › Modules turns it on for that application alone. A cache setting then names the inputs that vary its copies, and a Set Cache Policy rule applies that setting to the requests it matches. Use Application Accelerator to cache a personalized page, an API response that changes with a query string, a catalog that differs by device, or a response to a POST.

Cache setting structure

Application Accelerator acts through the modules.application_accelerator object of a cache setting, which Azion Console shows as the Application Accelerator section of the setting. This cache setting keeps a product listing for 30 seconds and gives each value of its category argument a copy of its own, sent as the body of POST /v4/workspace/applications/<application-id>/cache_settings:

• modules.application_accelerator holds the four Cache vary by controls: cache_vary_by_querystring, cache_vary_by_cookies, cache_vary_by_devices, and cache_vary_by_method. A control the body leaves out keeps its default, ignore, or an empty list for the methods.
• behavior takes ignore, all, allowlist, or denylist, and the device control takes ignore or allowlist. Here, allowlist varies the key only by the arguments in fields, and sort_enabled groups every order of them under one key.
• max_age set to 30 is accepted only while Application Accelerator is on. Without it, the floor is 60 seconds, and Azion API refuses a lower value with 21021.
• The switch belongs to the application, not to the cache setting. PATCH /v4/workspace/applications/<application-id> turns it on with { "modules": { "application_accelerator": { "enabled": true } } }, and while it is off, the API refuses any field of modules.application_accelerator with 21013.

If you configured a Vary header or a cache-key rule elsewhere, the model transfers. You name the inputs that make two requests different, and each distinct value gets its own copy.

Request path

A cache key is the index entry for a cached object. By default, Azion builds it from the scheme, the host, and the path of the request, so each path is one object in cache. While the query-string control stays at its default, ignore, a query string does not split that object. Each variation a cache setting turns on adds one input to the key, and each kind appends its own marker:

• A cookie variation appends the @@ separator, then the names and values of the cookies, each followed by ;.
• A device variation appends @@ and the name of the device group.
• A cached POST or OPTIONS response appends @@ and the MD5 hash of the request body.
• A query-string variation appends the query separator and the chosen arguments, in the order the request submitted them. The arguments are already part of the URL, so this variation needs no @@.

A request that uses any method other than GET or HEAD is a complex request, and its key carries the method as a prefix. This diagram shows what the default key is built from and what each variation adds to it:

A cookie variation on a user cookie produces a key shaped like httpwww.example.com/@@user=user;. For a cached POST, the key is shaped like httpsdynamic.example.com/path@@md5_of_post_arguments. Two requests share a cached object when they produce the same key, and they get separate objects when they do not. For the full format and every input a key carries, refer to Cache keys.

For what the switch unlocks, the cost of a variation, purges, and how Bypass Cache differs from a time to live (TTL) of 0, refer to Cache variation.

Scope and limits

• Application: the switch is off on a new application, and it belongs to the application, so one application can carry it while another does not. Turning it on changes no traffic by itself. The controls of a cache setting start at ignore, and a cache setting reaches a request only through a Set Cache Policy rule. For the switch, refer to Main Settings.
• What the switch unlocks: cache variation, the caching of POST and OPTIONS responses, and a Max Age as low as 0 seconds. It also unlocks seven more Rules Engine behaviors and the ${request_uri} and ${device_group} variables, and an application takes all of these or none. The behaviors are Add Cookie, Bypass Cache, Capture Match Groups, Filter Request Cookie, Forward Cookies, Rewrite Request, and Run Function. Beyond the GET and HEAD an application accepts natively, the switch adds OPTIONS, POST, PUT, PATCH, and DELETE. Of those, only POST and OPTIONS responses can be cached.
• Variation size: each distinct value of a varied input is a separate cached object. A cookie unique to each visitor gives every visitor a copy, so the number of objects grows with the audience instead of with the content. For how an allowlist and Sort bound that number, refer to Cache variation, and for the practices, to Applications best practices.
• Purges: cookie and device group variations survive a URL purge. A cache key purge reaches them, and so does a wildcard purge that ends the key with @@*. Query-string variations are the exception. A URL purge reaches them when it sends the arguments in the order they were presented, or in alphabetical order with Sort on. For the purge types, refer to Real-Time Purge.
• Bypass Cache and a TTL of 0: Bypass Cache sends each request its rule matches to the origin and caches nothing in Azion’s cache. It does not reach the Tiered Cache layer. A Max Age of 0 seconds keeps the request on the cache path, so parallel requests for one object reach the origin as one request. For when to use each, refer to Bypass Cache and a TTL of 0.
• Neighbors: Application Accelerator decides what goes into a key, and Cache then keeps a separate copy for each value. Varying the cache on the ims string of Image Processor needs Application Accelerator, while processing an image does not.
• Interfaces: you turn on the switch in Azion Console, through Azion API at /v4/workspace/applications/<application-id>, and with azion update application --application-accelerator in Azion CLI. azion.config.js sets it with applicationAcceleratorEnabled, and Azion Lib with application_acceleration on an update. Azion Terraform Provider manages the application resource that carries the switch. The variation controls belong to the cache setting, at /v4/workspace/applications/<application-id>/cache_settings or through azion create cache-setting flags such as --cache-by-query-string and --cache-by-cookies. No flag of azion create cache-setting sets device-group variation or the cache Max Age, so send them in a --file body.
• Observability: with Pragma: azion-debug-cache on a request, the x-cache-key header of the response shows what each variation added to the key. A POST reports - in x-cache until the cache setting names POST in Cache vary by Method. To read the same headers in a browser, refer to Verify cache indicators.
• Limits: with Application Accelerator on, Max Age goes down to 0 seconds, or to 3 seconds when the cache setting also has Tiered Cache on. Turning it on can generate usage-related costs. For each TTL bound, the answer past it, and what each plan includes, refer to Applications limits, and for the rates, to Pricing.
• Terms: the Applications glossary defines the words the Application Accelerator pages give a specific meaning, such as Advanced Cache Key, allowlist, denylist, and complex request.

Next steps