Performance

Managing caching

Edge Caching is available if you want to take advantage of the performance and speed improvements, but do not have a caching solution of your own in place.

🌟 Edge Caching Benefits

  • Faster page load times for end-users

  • Lower latency

  • Increased load capacity and reduced application server load

  • Better ratings from search engines such as Google

By default, ThreatX Edge Caching follows Cache-Control headers defined by the origin servers.

The ThreatX platform does not cache for the following response scenarios:

  • Cache-Control is set to Private, No-Cache, or No-Store

  • Response headers include Set-Cookie

  • We are responding to POST requests

The ThreatX platform offers two types of Edge Caching: static and dynamic.

Caching can be enabled for a configured site as described in sites.adoc#site-settings

Static caching

Static caching is configured to cache static elements such as images, CSS & JavaScript. Static caching does not store HTML pages and as a result does not enhance performance if the origin server becomes unresponsive.

Static Cache Settings
Default cache expiration

30 minutes.
Supported static file extensions

jpg, jpeg, gif, png, ico, bmp, tif, tiff, svg, svgz, swf, pict, cur, doc, docx, xlsx, ppt, pptx, pdf, woff, woff2, eot, otf, js, ejs, css
Support for non-responsive origin servers

No.
URI Specific Caching

Per-URI features can be enabled, overriding the origin server values.
Manual Cache Purging

Can be purged by ThreatX SOC upon request. Purging can be limited to a specific URI.

Dynamic caching

  • Dynamic caching offers a higher level of performance, allowing caching and optimization of dynamic content.

  • In some cases, cached content can be delivered even if the origin servers are unresponsive.

  • The ThreatX platform caches all responses to requests made with HTTP GET and HEAD methods.

  • To avoid caching dynamic pages that are rarely accessed, ThreatX sensors cache dynamic pages only after they are requested at least 3 times.

  • Subsequent requests are served from the cache until the cache expiration defined in the Cache-Control occurs (or about 30 minutes for responses where the expiration is not defined).

Dynamic Cache Settings
Default cache time

30 minutes
Time-to-cache

Can be configured by ThreatX SOC upon request.
URL based caching

Can be configured by ThreatX SOC upon request
Supported file types

Any dynamic resources
Support for non-responsive origin servers

500, 502, 503, and 504 response codes. Can be configured by ThreatX SOC upon request.
Supported request methods

GET, HEAD
URI Caching

Per-URI features can be enabled, overriding the origin server values.
Manual Cache Purging

Can be purged by ThreatX SOC upon request. Purging can be limited to a specific URI.
Dynamic caching is a billable feature and requires an add-on license.

Managing rate limiting

The ThreatX platform rate limiting is in the form of rules in the common rule set. Rate limiting is primarily focused on count and time frame. What causes a rule to trigger when based off count and time frame is limited only by what the rules can match within the requests. For example, one rule is 10 404s in 10s, where the rule assigns risk to an entity that receives more than 10 404 responses within 10 seconds.

As needed, the ThreatX SOC team can make custom rate limiting rules tailored for your environment. A typical use of this would be to assign risk to entities that fail logins at a login endpoint. These rate limiting rules are very customizable, including the timings (number of requests over time). These rules can be applied across the entire tenant, down to a site or group of sites, or to a single endpoint. The match criteria also have a very wide range of options such as Response Code, Request Method, Source Country/ASN, and Arguments.