aiCache Web Application Acceleration Blog

aiCache makes it possible to control whether or not a web page is cacheable, based on page’s (response) content. For example, www.acmenews.com/breakingnews.aspx web page is normally cached for 10 seconds, unless editorial team decides to publish a survey (poll) on that page, in which case you cannot cache the page for as long as the poll is active. As soon as poll is removed from the page, you can restore the caching back to 10 second.

aiCache offers support for this kind of scenarios via so called “Content Driven Caching” or CDC for short. Here’s how it works.

First, you define a cacheable pattern, just as usual. Then you add one or more of cdc_pattern pattern-level settings under the matching pattern, specifying regular expression match strings. With these specified, aiCache will analyze response bodies, looking to match the response body to a defined cdc_pattern.

Should a match be found, aiCache temporarily overrides TTL for the matching response and sets it to 0. Effectively, the matching web page is declared non-cacheable. Periodically, aiCache will attempt to match the page’s content again and should no match be found, the page will have its TTL restored back to the one specified by the pattern. You can control how frequently such-rechecking is done by setting cdc_interval pattern level setting, it defaults to 5 seconds.

website www.acmenews.com
…
pattern breakingnews simple 10
cdc_pattern acme\spoll
cdc_pattern acme\ssurvey

In the example above, we match response’s body (content) to see if contains “acme poll” or “acme survey” in it. Should a match be found, aiCache will declare the page non-cacheable and no longer serve it out of cache. Sometimes, you might find it easier to match for auxiliary content URLs instead. For example, you might know that every time a poll is published on a page, the poll’s Javascript is included into the page so you can look for that Javascript URL instead. For example:

cdc_pattern userpoll.js
cdc_pattern usercomment.js
Matching for such JS “includes” might be less resource intensive, as they are often located at the very beginning of the page’s HTML, so aiCache can find the match faster.

Let’s consider another situation. Acmenews’s editorial team might decide to publish polls or enable comments, in any of the following pages: usnews.jsp, worlnews.jsp, marketnews.asp and cenews.asp. As you can see, all of these URLs have a common “news.jsp” component to them , so you can create a single pattern to cover all of them:

website www.acmenews.com
…
pattern news.jsp simple 10
cdc_pattern userpoll.js
cdc_pattern usercomment.js

Now all of the mentioned pages will have their content analyzed for CDC-overrides, independently of each other. In other words, usnews.jsp might end up in CDC-override state, while worldnews.jsp is still served from cache.

The handling of page with the CDC-overridden TTL is no different from the way 0TTL requests are normally handled by aicache. Specifically, all of the cookies are sent both to OS and back to the requesting client.

When page is in “regular”, cacheable state, aiCache only attempts to match the response body against the CDC patterns when the page is refreshed, so we recommend you keep TTL for such pages low enough, so aiCache can detect the change in the page’s content quickly enough. As mentioned earlier, when in “CDC-override” state, the matches are performed every cdc_interval seconds – every 5 seconds by default.

When aiCache needs to perform content matching for CDC patterns, it requests the response in plain, non-compressed form. This way no CPU cycles need to be spent by OS to compress the response and by aiCache to uncompress it, before matching could be performed. The response will be compressed by aiCache, in accordance with on-the-fly compression settings and client browser indicating support for compression

aiCache brings a new level of Web Acceleration to the market with the release of Version Six of its flagship product, aiCache Web Application Accelerator. With an architecture supporting and linearly scaling up to unlimited number of CPU cores, it provides virtually unlimited scalability for HTTP and HTTPS traffic.

aiCache solves the industry issue of slow SSL speeds and the need for expensive dedicated hardware, by bringing high speed SSL termination to the Cloud and Data Centers, on common hardware.

This is a special benefit for users of cloud and virtualization technology. Virtualization solutions such as Amazon Web Services do not allow dedicated hardware. Cloud customers have been without options for handling large scale SSL implementations until now. aiCache removes the SSL barrier by running in virtualized instances, providing dedicated hardware level performance.

Version Six supports over 250,000 transactions per second for non-encrypted content and over 30,000 RSA1024 SSL sessions per second, all running on a single server.

aiCache manages HTTPS and HTTP traffic, relieving web servers from the overhead of encryption,, while providing a superior customer experience and delivering full complement of industry-leading aiCache Web Application Acceleration features.

The new release fully supports earlier configuration file syntax, allowing existing customers to simply drop-in a replacement binary.

Customers in the Cloud, with Amazon Web Services and Rightscale, will have the Version Six capabilities available at no additional cost.

aiCache allows you to cache a site’s content and enforce the registration/login policy. Users that are not logged in or registered, will not be allowed to view cached content and will be subject to normal handling; i.e. “asked to register and sign in to view the content.”

You might need a method to allow reporting of assorted error conditions. For example, your web site might offer videos, breaking news and other APIs that are invoked by AJAX or some other form of client-side Javascript. When these APIs fail to respond, you would like to have some way to report the error condition so that it can be recognized, logged and acted upon.

Normally, accomplishing this requires writing custom server-side code that would receive the error notification and execute some form of reporting, logging and alerting function. However, outside of having to write such code, you might face another danger when following down this path: when in error state, your site will be receiving large number of error message and that in itself, can cause further deterioration of service which would result in even more of error conditions being reported. In just few quick seconds you whole site just might melt down.

aiCache offers an easy way to accomplish the required functionality, without requiring any custom code to be written or any code to be executed by your web, application or database servers. It is aiCache that receives, logs and alerts on error condition, without ever forwarding any of the traffic to the rest of your infrastructure.

Reporting using a dedicated error reporting website.

To accomplish this, setup a dummy website in aiCache, for example error.acmenews.com . Identify the site as dummy website via dummy_website website-level configuration directive. You don’t need to specify any origin server for websites defined as dummy, as no requests ever are sent to origin servers for such websites.

Setup the site to alert on when number of requests exceed the desired threshold – for example set alert_req_sec_max to alert when this website receives more than 2 requests per second.

Setup the client side code to execute a simple HTTP GET against this website, passing arbitrary URL and parameters, as part of the request. For example, to report a problem with your News API, you might request http://error.acme.com/app=newsapi&errorcode=123&client=premier . It is up to you just what parameters you want to pass via such a request.

Now, when an error condition is detected, a request is made to the specified URL. aiCache receives the request and logs it. When number of such requests exceed the configurable threshold, an alert is sent out. So there you have it: without writing any of the server side logic and without placing any extra load on your infrastructure, you now can receive, log and alert on error conditions – all courtesy of aiCache.

It doesn’t have to be only the client-side logic that sends such error-reporting requests. You can use method of your choosing to execute such requests – including server-side code, custom script etc. You can also redirect clients to the error-reporting URL in case of a problem that you discover when executing some logic. Again, you’re only limited by your imagination in how this functionality can be deployed.

You can train your personnel to look at the aiCache log file for such error reporting web sites, when the error condition is reported and alerted by aiCache, to see the additional information that is embedded inside of the error reporting URLs (such as application, error code and client information in the example above).

To assist in rapidly detecting the error condition, aiCache lights up the respective web site name in red, in its self-refreshing web monitor screen, when it detect that RPS for a dummy website exceeds the set limit. This is in addition to regular email alerting on the error condition – which should be configured as per instructions in Automated Alerting and Monitoring section of this manual. Specifically, you must provide the email address to send the alert to, at either or both global and website levels.

Reporting using pattern attribute.

You can set a bad_response pattern flag. When aiCache matches a request to such pattern, the response is reported as bad response (same as say 5xx response code) – so you can monitor for such bad responses, log and alert on them.

Here’s an example explaining how you can use this feature. Some sites have dedicated pages setup for common errors – such as PNF (page-not-found) and similar. So let’s imagine there is such a dedicated error page called 404error.html . The page is requested/redirected to in response to assorted error conditions, as detected by assorted server and client side code.

By setting bad_response flag for matching pattern, you will configure aiCache to report and optionally, alert on, whenever this page is requested, providing for 0-cost monitoring and alerting of this error condition.

Please note that setting of bad_response flag doesn’t affect anything else in terms of request/response handling logic, its sole purpose is for reporting and optional alerting of matching traffic.