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 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.

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.

aiCache provides an elegant solution to this with pre-fetch technology.

aiCache allows you to configure a set of slower URLs to pre-load. It then pre-fetches and actively maintain a queue of fresh responses When these are requested, aiCache instantly serves the pre-fetched response.

By tailoring pre-fetch settings you can optimize the site so all responses are pre-fetched. aiCache collects and reports on pre-fetch statistics simplifying this task.

Each second, aiCache analyzes the queues of the advertising URL’s. When a queue contains too few responses, aiCache requests additional ads to maintain the optimum number.  When a request comes for any advertising URL, aiCache removes a response from appropriate queue and sends it to the browser. The result is the website never waits for an advertising response.

aiCache provides a few seconds of queuing, ensuring an accurate set of statistics for served ads allowing accurate fast serving of content that scales independent of the performance of the advertising API.

A site serving mobile clients might serve responses whose formatting depends on exact mobile device/browser. To accommodate for such clients, while allowing for caching of responses, we must use User Agent information as part of cached response signature.

When a URL named “news.html” is accessed by 3 different mobile devices, we shall have 3 different responses cached – each containing mobile device’s User Agent string.

Using this feature has the potential to significantly increase the size of response cache (as multiple versions of same URLs are now cached). To solve this problem aiCache provides:

Using reduced/rewritten User Agent string in signature of cacheable responses.
This feature is only available in mobile-enabled edition of aiCache.

Related to the previous feature, this allows you to rewrite/reduce User-Agent strings to a smaller subset and use the rewritten/reduced values as part of cacheable response signature.

The problem this feature addresses has to do with a great variety of mobile devices currently available. Every firmware revision, different mobile providers/carriers/market all result in a different User-Agent strings sent by mobile device, making it a challenge to accommodate for all of these devices.

The great majority of mobile devices on the market can be reduced to about a dozen distinctly different devices (device families). So Blackberries can be grouped into may be 2 different sets, Iphones’s into its own set and so on, based on capabilities, support for Javascript and available screen sizes.

aiCache allows you to accomplish just that. You specify rewrite rules for User-Agent strings. The rewritten/reduced User-Agent strings are then used as part of signature of cached responses.

The same “compressed” User-Agent string is also forwarded as X-UA-Rewrite header in requests sent to origin servers. The origin servers (server-side code) can then programmatically access and act on this header value, with a goal of modifying responses to accommodate for mobile device differences.

-For example resorting to Javascript-free versions of content for devices that don’t support Javascript, resizing the images to accommodate for different screen sizes.

The server-side code can also tailor the responses based on the actual value of User-Agent string (aiCache never modifies it, it is forwarded verbatim from requesting device to the origin servers) – but then the server-side code has to accommodate for a much larger variety of devices.

Reducing the large number of different User-Agent strings to a much smaller subset also has a positive impact on caching of responses – allowing to achieve much higher cache hit ratios and to proportionally reduce the traffic and demands on origin server infrastructure (Web Servers, DB servers etc).

It also allows to greatly simplify the logic required to handle the variety of mobile devices available on the market today.

It is most desirable to accommodate for different mobile devices in a fashion that doesn’t require changing the URLs – so that no matter what mobile device is being used, News page is always accessed as /news.html, Sports section is always /sports.html.

The normal solution where URLs change, say by prefixing every URL with a device type, to accommodate for the device type is confusing to the customer.

aiCache provides a manageable elegant solution to these issues.

By default, Aicache uses hostname  and URL of request, possibly sanitized by removing some parameters or discarding the complete query string, as a signature of (pointer to) cached responses.

Some sites might serve different cacheable content in response to requests for same URLs,  depending on a value of a User Agent HTTP header present in the request.

User Agent HTTP Header identifies browser’s make and model.

A site serving mobile clients might serve responses whose formatting depends on exact mobile device/browser. To accommodate for such clients, while allowing for caching of responses, we must use User Agent information as part of cached response signature.

When a URL named “news.html” is accessed by 3 different mobile devices, we shall have 3 different responses cached – each containing mobile device’s User Agent string.

To enable such behavior, you can specify sig_ua setting  in website section of the configuration file.

All of the cacheable requests for to the  website shall now have User Agent information appended to their signatures – you can see that when you run CLI inventory command or its derivatives (sit, sir, sis, sif).

Tthis feature has potential to significantly increase the size  of response cache (as multiple versions of same URLs are now cached), so we recommend using it only when necessary.

Excellent for accommodating mobile clients.

You can also combine sig_ua and sig_cookie (see admin guide) settings – in which case both the selected cookie value and User Agent string are used as part of signature. In this case it is the User Agent string that becomes the signature’s suffix.

Press

Your site is humming along quite nicely when all of a sudden your monitoring screens light up red and site slows to a crawl. A minute later it is down and no responses are getting back to the clients. Where do you start looking to understand what’s going on? What do you do to restore the service ASAP? How do you make sure it doesn’t happen again?

With aiCache front-ending the traffic problem resolution becomes a straightforward exercise. A divide’n'conquer approach is in order – we need to understand what component is ailing and what traffic patterns are prevalent.

This is where you start: pull up the aiCache Web monitor – it will show all of the domains aiCache is accelerating. Look to see which ones are showing highest client/origin server session counts, slowest response times and highest increases in traffic.

aiCache displays all of that information in real time – refreshing it every few seconds! You instantly see which site is getting hammered with traffic . aiCache displays average requests/second in last 5 seconds, last minute and last hour. You quickly see what site saw the highest traffic jump.

The all-websites-overview screen allows you to zoom into a particular site or see list of pending origin server requests – this one is likely to provide a list of URLs that are unable to obtain quick responses from origin servers, per website, in real time again.

Many setups share components so that after a spike against one of services/sub-domains, in 10-20 seconds the whole site comes to a screeching halt.

How do you reconstruct the sequence of event? Again, Aicache come to the rescue – it collects 5-second snapshots of traffic and stores it both in aiCache memory, where it can be instantly pulled up for each of the accelerated websites, and in the statistics log files – one per each accelerated domain.

You can use “runstat” CLI command or look at the statistics log file to see what domain started seeing elevated traffic levels and/or slower response times from origin servers first.

You can also use CLI’s “inventory” commands, the “sorted by fill time, number of requests, number fills” variety to see the most requested URLs, the slowest URLs to obtain – again, for each subdomain.

You narrow your search down to a failing domain. It is still unclear how to go about fixing it, yet you want to restore the service so that all the other domains/services can start working again.

The easiest way to accomplish that is put the ailing sub-domain into “fallback” mode. This way it continues to serve cached and possibly stale content, while completely disengaging the origin servers, letting your team members concentrate on restoring that service.

For a busy website, use of fallback command has another important benefit – as aiCache now either instantly delivers a cached (possibly stale) response or, equally instantaneously, sends an error message to the client, you stop the uncontrolled growth of session counts on your network/security devices and begin dissipating these.

Bottom line: with aiCache in the path of traffic, understanding, troubleshooting and recovering of websites becomes a fairly easy and straightforward exercise. The benefit of understanding traffic flows, in real time, is reason to insert aiCache into the path of your web traffic, while providing a host of additional benefits!

aiCache: Get your life back …

aiCache instances can reduce resource utilization in the web farm by 50 to 80% by capturing traffic before it hits the web, application and database servers. The availability of Amazon EC2 instances allows companies, for the first time, to move their traffic from their local data-center to the take advantage of the stability and speed and stability of aiCache, while leveraging the world class infrastructure of Amazon.

Applications already on Amazon can immediately take advantage of the aiCache, by simply by initiating the aiCache AMI from the Amazon Solutions Catalog.

aiCache uses the KITE Testing Environment. KITE allows validation of your application running on aiCache & Amazon, while providing real-time perfomance reporting from five global locations.

The combination of Amazons instant scalability, acceleration and rich reporting from aiCache and the Global monitoring capability of KITE make a powerful combination for businesses looking for scale, stability and cost reduction.

“We feel the Amazon Elastic Compute Cloud,
with its ability to run the 64 Bit Linux instances, that make the aiCache technology possible, is the best of all possible worlds for on-demand growth. With Amazon providing hourly billing these instances can be configured for hours, weeks, or on a permanent basis, depending on the needs of our customers.

We created this service to allow set-up, testing, and validation, all without interruption of the existing application. We have made it as easy to realize the advantages of virtualization and caching in the cloud. We look forward to helping customers build better, more scaleable applications; the kind that let them spend their evenings with their families. -Max Robbins COO aICache.

aiCache cloud pricing and order details can be found on the the aiCache Amazon Order Page

Official Press Release

With more than one aiCache server deployed, it makes sense to manages such collection of servers as a “cluster” – so that certain commands are applied cluster-wide, without having to repeat them on each server separately. Most noticeably, when we expire content on-demand, manually via CLI or Expire-Header response-driven expiration, we want to make sure requested content is expired on all of the aiCache servers.

Likewise, should we ever need to place site into administrative fallback mode, we’d want each and every aiCache server to go into fallback mode without having to do it at each server separately.

To support this type of behavior, aiCache uses notion of a peer. When one or more peers are defined, aiCache notifies all defined peers about both expiration and fallback commands – no matter how they were triggered, CLI or otherwise.

To enable and define peers, simply add one or more of “peer peer_IP [optional peer_PORT#]” directives in the global section of the configuration file. For example the following snipped defines 3 peers, all running on port 81:

peer 1.2.3.4 81
peer 1.2.3.5 81
peer 1.2.3.6 81

The port setting is optional, it defaults to port 80. So the following snippet defines same 3 peers running on standard port 80:

peer 1.2.3.4
peer 1.2.3.5
peer 1.2.3.6

To communicate expire and fallback commands to peers, aiCache sends a specially crafted HTTP request to each configured peer. Peer request is identified by a special URI prefix with default value of “xaicachepeer”. You can change it via peer_prefix configuration setting in the global section:

peer_prefix supersecretpeerprefix

You might want to change it to your own string to safeguard peer commands. Clearly all of the peers must have peer_prefix setting set to the same value. Please make sure peer_prefix and stat_url settings are set to different values so that one is not a prefix of the other.

With peers enabled, aiCache servers communicate with each other upon receiving expire and fallback commands. Proper messages are shown and/or logged on both the sending Aicache instance and receiving aiCache instance(s). The command, command’s parameters, the sending aiCache server and the receiving aiCache server(s) are all identified.

The commands received from peers are not retransmitted, it is the sender that communicates to each defined peer via a one-to-many communication. You can have aiCache identify it’s own IP address as a peer – in case you want to maintain the same, bit-for-bit identical aiCache configuration file on a number of aiCache servers.