aiCache Web Application Acceleration Blog

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.

aiCache uses the hostname and URL of request  as a signature of  cached responses. Some sites require different cacheable content in response to requests for the 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.

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.

aiCache now has the capability to add User Agent string to signature of cacheable responses.

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