SSL offloading plus RAM cache

Yes. It is possible.

 

 

My suggest for verification is to create a custom HTTP Profile and enable ramcache on it (this is solely so that you can verify that nothing else is using that HTTP Profile). Apply it to your HTTPS Virutal Server (you will need to do SSL Off-load / configure SSL Profile (Client) at a minimum).

 

 

Hit the site a couple of times to allow the files that qualify to be put into cache.

 

 

Login CLI and run the following:

 

b profile http (Your.Custom.HTTP.Profile.Name) ramcache entry show all

 

 

This will show you all of the files that the BigIP is caching in memory (note the inclusion and exclusion settings in the HTTP Profile).

 

 

If you want to see the status / a list of all configured HTTP Profiles and their ramcache settings run:

 

 

b profile http all ramcache show

 

 

Hope this helps.

Sorry. Side note.

 

 

If you are running Administrative Domains and Partitions, you will need to be in the same partition that the HTTP Profile is in for this to work.

 

 

I suggest creating the HTTP Profile in the "Common" Partition. Otherwise you might have issues in the future if you ever want to flush the ramcache (b profile http (Your.Custom.HTTP.Profile.Name) ramcache entry all delete).

 

 

You may get this error "01070826:3: Current Update Partition Error: The current update partition (Common) does not match the object's partition (Other.Partition.Name), stats not reset". This ties to a Solution that mentions the VIPRION (http://support.f5.com/kb/en-us/solutions/public/12000/500/sol12510.html), but I experienced the same issue on a 6400.

Thanks! I was sure follow what you said and found out something very interesting: I never had RAM Cache fully working. Turns out that before offloading ssl on the VS I didn't properly verify the file (32 meg) was added as an entry. After SSL, I was looking at that so... yeah.

 

 

So, after pulling all of my hair out, having F5 support "get back to me" a few times, I found that the only way I could get RAM cache to work was to enable mirroring on the pertinent VS... makes no sense to me and I am guessing this is something that just makes a broken thing work. One of the reasons I feel this is getting this error when and only when I attempt to cache and download a relatively large about from cache:

 

 

Limiting open port RST response from 251 to 250 packets/sec

 

 

Considering getting 5-10 of these in a row causes "Clock advanced by 102 ticks", I am very concerned.

 

 

Oh, and yes, SSL offload + RAM cache is working. Thanks again!

 

I would try to work with support to figure out why this isn't working without connection mirroring enabled. There is no reason to enable connection mirroring for most HTTP/S applications as the additional CPU usage doesn't justify the feature.

 

 

I'd also be concerned about the clock advanced alerts as it indicates TMM is too busy to answer heartbeat messages:

 

 

sol10095: Error Message: Clock advanced by ticks

 

http://support.f5.com/kb/en-us/solutions/public/10000/000/sol10095.html

 

 

Aaron