Hot Cache: The Hot Cache is what you would see on a BigIP LTM device if you were to use an HTTP Class with RamCache enabled, the hot cache (RamCache) allows some limited caching functions and is bundled as one of the features built-in to the BigIP LTM device. This type of caching provides functionality much like a caching proxy server would in that the LTM will stand in proxy to the application server and request content on the client’s behalf – all normal application-generated caching rules apply however. Hot Cache maintains an in-memory cache of objects throughout their lifecycle.

Smart Cache: The Smart Cache is a Hot Cache on steroids, in the middle of ‘roid rage. Smart Cache is what happens when you add the Web Accelerator (WA) module into a BigIP LTM. Smart Cache is a little different from hot cache in that it not only maintains an in-memory set of the most used objects and objects which are not intelligently cached via IBR, but also does disk-based caching of other objects which have not yet been deemed invalid (IBR objects). The disk cache allows the WA to perform intelligent caching, allowing some objects to remain cached forever even if they never change on the server. The implications are insane especially for fairly static applications/sites.

Share on Facebook

Now here’s something I wouldn’t expect to see outside of a test environment. Anyone that’s worked with web acceleration or web caching knows how easy it is to allow applications to expose the wrong data to the wrong client if you’re not setting your policies properly.

A woman logged onto facebook on her AT&T cellular phone and got ‘GASP’, someone else’s facebook account!!!

Never having worked with proxying on the ISP level, I wonder how much caching and acceleration AT&T or the other big mobile carriers are doing for their customers. I can imagine they may be dabbling with it a bit as cell phones have limited data capabilities too.

The danger here is if AT&T was web acceleration/caching on some of the more well known and widely used sites out there, such as facebook as requests entered/exited their network. Not knowing the ins and outs of the application of which you’re caching is one of the worst things you can do in web acceleration, and no doubt can VERY EASILY lead to something like this occuring.

I’ve actually managed to do something like this in a test environment before and it was quite interesting. Application X was being cached by an F5 Web Accelerator and no matter what I did, every time the RamCache was enabled and clients logged in, they would not necessarily get their intended session, sometimes (most of the time) they would get hooked into someone else’s session and was able to do, think and act as if they were some other user-possibly a privileged user even. It turns out that a simple iRule fixed the problem – disable the RamCache only for the specific file which acted much like a ‘controller’ for the application in general, not necessarily needing to be cached really anyway.

Here’s the iRule I used, very simple:

when HTTP_REQUEST {
if { [HTTP::uri] contains ".extension" } { CACHE::disable }
}

Source: Fox News, Personal experience

Share on Facebook

For anyone trying to implement Oracle EnterpriseOne on F5 BigIP LTM with Web Accelerator module; and although it’s mostly not recommended by F5 to do this, you’ll need an iRule to make E1 8.11 to work with Web Accelerator.

With RamCache enabled (as is required for Web Accelerator to function), some of the content in the dynamic .maf files served by EnterpriseOne gets cached and held in RamCache; it seems for some reason (and it still may be my ‘greenness’ to the F5 WebAccel) that this data is not getting moved from Hot Cache to Smart Cache, as after a few logins, causes some users to experience session re-use from other users. Very bad!

It seems that no matter what I tried to do to exclude/proxy only the .maf files in WA, they keep getting caught in RamCache (Hot Cache) and held for way too long.

In order to stop this behaviour, just use an iRule to disable cache for .maf file requests:

when HTTP_REQUEST {
if { [HTTP::uri] contains “.maf” } {
CACHE::disable
}}

That’s that! Use the F5-provided WA policy for Oracle EnterpriseOne ERP and you’re set!
If anyone has happened to know of another way to deal with this or has managed to use WA on E1 8.11 WITHOUT having to do this, I am all ears… show me how it’s done!

Share on Facebook