APM inactivity timeout redirect or notification page for LTM + APM connections
Background on this: Have a customer that is publishing a Microsoft CRM instance behind APM and doing KCD with smart card auth. Access policy works fine, KCD works fine, web app works fine. The only problem we have is the inactivity timeout setting. Once the limit has been reached, the session is removed and content is no longer sent to the user in a very abrupt fashion. This is a problem because ALOT of the page is cached on the clients workstation and all they see is broken JPEGs and incomplete web content. Once they click around they are re authenticated but it is not pretty. I want to find a way to notify the user they have been inactive for a certain amount of time, send a HTTP 200 response with content notifying them with a link to click on to re authenticate. The option of increasing the inactive timeout is not an option due to their access session license limit. There would be alot of abandoned sessions that would aggregate potentially going over this limit. I know with webtop and ssl vpn, you get a notification that you are about to be logged out due to inactivity but this doesn't seem to be available for LTM + APM policies. This is what I have so far, there has to be a more efficient way of doing this though. when ACCESS_SESSION_STARTED { set ::EXPIRE "false" } when ACCESS_SESSION_CLOSED { log local0. "Session has been closed" set ::EXPIRE "true" } when HTTP_RESPONSE { if {$::EXPIRE equals "true"} { HTTP::respond 200 content " You've Been Logged out due to inactivity You have been logged out due to inactivity Thanks for Using the application Click to log back in. " } }
Session size garbage after an AD query, can I remove them?
Hello community, I'm using our BigIP as an IDP and we have about 20 federations to date. They all share the same VP and iRule. One of the federations need to know, if somebody logs in and they are a manager, how many employees do they have. I have found that this generatea lot of session variables, and I worry that I will exhaust the cache. So I wonder if there is any way to discard these session variables or mark them as garbage orsomething, because while it might be okay with these leftovers for managers with five employees, it's not okay for managers with five hundred! I'm curious if there is any way to discard these variables to exclude from the session? This is what I do: I use the following LDAP filter to get all enabled users that has them in the manager attribute: (&(manager=CN=%{session.logon.last.username},OU=Users,OU=Organization,DC=Corp,DC=net)(!(userAccountControl:1.2.840.113556.1.4.803:=2))) The filter works fine. To not make the query too expensive, I tried limiting the query to only the "c" attribute (country), which contains two letters only. However, dn is included and I can't change that, so I removed the "c" attribute. This generates session output like this: 9543782a.session.ad./Common/ad_query_employees_act_active_directory_query_ag.attr.dn CN=Tobias Anderson,OU=Users,OU=Organization,DC=Corp,DC=net 9543782a.session.ad./Common/ad_query_employees_act_active_directory_query_ag.attr.dn.1 CN=Philippe Hudson,OU=Users,OU=Organization,DC=Corp,DC=net 9543782a.session.ad./Common/ad_query_employees_act_active_directory_query_ag.attr.dn.2 CN=Jonas Gabriel,OU=Users,OU=Organization,DC=Corp,DC=net 9543782a.session.ad./Common/ad_query_employees_act_active_directory_query_ag.attr.dn.3 CN=Ted Miles,OU=Users,OU=Organization,DC=Corp,DC=net 9543782a.session.ad./Common/ad_query_employees_act_active_directory_query_ag.attr.dn.4 CN=Lars Hedin,OU=Users,OU=Organization,DC=Corp,DC=net 9543782a.session.ad./Common/ad_query_employees_act_active_directory_query_ag.attr.dn.5 CN=Tomas Jeffrey,OU=Users,OU=Organization,DC=Corp,DC=net ... Now, I only care about how many employees they have, not who they are. As it stands now, we'll be populating a custom attribute in AD with this information instead, but I'm curious because we might end up with similar applications in the near future that may produce unwanted variables. Surely there must be some garbage collection functions or unset functions to tidy up our sessions? How would you guys implement this? Any ideas?What is HTTP Part VIII - Compression and Caching
In the last article of this What is HTTP? series we covered the nuances of OneConnect on HTTP traffic through the BIG-IP. In this article, we’ll cover caching and compression. We’ll deal with compression first, and then move on to caching. Compression In the very early days of the internet, much of the content was text based. This meant that the majority of resources were very small in nature. As popularity grew, the desire for more rich content filled with images grew as well, and resource sized began to explode. What had not yet exploded yet, however, was the bandwidth available to handle all that rich content (and you could argue that’s still the case in mobile and remote terrestrial networks as well.) This intersection of more resources without more bandwidth led to HTTP development in a few different areas: Methods for getting or sending partial resources Methods for identifying if resources needed to be retrieved at all Methods for reducing resources during transit that could be successfully reproduced after receipt The various rangeheaders were developed to handle the first case, caching, which we will discuss later in this article, was developed to handle the second case, and compression was developed to handle the third case. The basic definition of data compression is simply reducing the bits necessary to accurately represent the resource. This is done not only to save network bandwidth, but also on storage devices to save space. And of course money in both areas as well. In HTTP/1.0, end-to-end compression was possible, but not hop-by-hop as it does not have a distinguishing mechanism between the two. That is addressed in HTTP/1.1, so intermediaries can use complex algorithms unknown to the server or client to compress data between them and translate accordingly when speaking to the clients and servers respectively. In 11.x forward, compression is managed in its own profile. Prior to 11.x, it was included in the http profile. The httpcompression profile overview on AskF5 is very thorough, so I won’t repeat that information here, but you will want to pay attention to the compression level if you are using gzip (default.) The default of level 1 is fast from the perspective of the act of compressing on BIG-IP, but having done minimal compressing, reaps the least amount of benefit on the wire. If a particular application has great need for less bandwidth utilization toward the clientside of the network footprint, bumping up to level 6 will increase the reduction in bandwidth without overly taxing the BIG-IP to perform the operation. Also, it’s best to avoid compressing data that has already been compressed, like images and pdfs. Compressing them actually makes the resource larger, and wastes BIG-IP resources doing it! SVG format would be an exception to that rule. Also, don’t compress small files. The profile default is 1M for minimum content length. For BIG-IP hardware platforms, compression can be performed in hardware to offload that function. There is a database variable that you can configure to select the data compression strategy via sys modify db compression.strategy . The default value is latency, but there are four other strategies you can employ as covered in the manual. Caching Web caching could (and probably should) be its own multi-part series. The complexities are numerous, and the details plentiful. We did a series called Project Acceleration that covered some of the TCP optimization and compression topics, as well as the larger product we used to call Web Accelerator but is now the Application Acceleration Manager or AAM. AAM is caching and application optimization on steroids and we are not going to dive that deep here. We are going to focus specifically on HTTP caching and how the default functionality of the ramcache works on the BIG-IP. Consider the situation where there is no caching: In this scenario, every request from the browser communicates with the web server, no matter how infrequently the content changes. This is a wasteful use of resources on the server, the network, and even the client itself. The most important resource to our short attention span end users is time! The more objects and distance from the server, the longer the end user waits for that page to render. One way to help is to allow local caching in the browser: This way, the first request will hit the web server, and repeat requests for that same resource will be pulled from the cache (assuming the resource is still valid, more on that below.) Finally, there is the intermediary cache. This can live immediately in front of the end users like in an enterprise LAN, in a content distribution network, immediately in front of the servers in a datacenter, or all of the above! In this case, the browser1 client requests an object not yet in the cache serving all the browser clients shown. Once the cache has the object from the server, it will serve it to all the browser clients, which offloads the requests to server, saves the time in doing so, and brings the response closer to the browser clients as well. Given the benefits of a caching solution, let’s talk briefly of the risks. If you take the control of what’s served away from the server and put it in the hands of an intermediary, especially an intermediary the administrators of the origin server might not have authority over, how do you control then what content the browsers ultimately are loading? That’s where the HTTP standards on caching control come into play. HTTP/1.0 introduced the Pragma, If-Modified-Since, Last-Modified, and Expires headers for cache control. The Cache-Control and ETag headers along with a slew of “If-“ conditional headers were introduced in HTTP/1.1, but you will see many of the HTTP/1.0 cache headers in responses alongside the HTTP/1.1 headers for backwards compatibility. Rather than try to cover the breadth of caching here, I’ll leave it to the reader to dig into the quite good resources linked at the bottom (start with "Things Caches Do") for detailed understanding. However, there's a lot to glean from your browser developer tools and tools like Fiddler and HttpWatch. Consider this request from my browser for the globe-sm.svg file on f5.com. Near the bottom of the image, I’ve highlighted the request Cache-Control header, which has a value of no-cache. This isn’t a very intuitive name, but what the client is directing the cache is that it must submit the request to the origin server every time, even if the content is fresh. This assures authentication is respected while still allowing for the cache to be utilized for content delivery. In the response, the Cache-Control header has two values: public and max-age. The max-age here is quite large, so this is obviously an asset that is not expected to change much. The public directive means the resource can be stored in a shared cache. Now that we have a basic idea what caching is, how does the BIG-IP handle it? The basic caching available in LTM is handled in the same profile that AAM uses, but there are some features missing when AAM is not provisioned. It used to be called ramcache, but now is the webacceleration profile. Solution K14903 provides the overview of the webacceleration profile but we’ll discuss the cache size briefly. Unlike the Web Accelerator, there is no disk associated with the ramcache. As the name implies, this is “hot” cache in memory. So if you are memory limited on your BIG-IP, 100MB might be a little too large to keep locally. Managing the items in cache can be done via the tmsh command line with the ltm profile ramcache command. tmsh show/delete operations can be used against this method. An example show on my local test box: root@(ltm3)(cfg-sync Standalone)(Active)(/Common)(tmos)# show ltm profile ramcache webacceleration Ltm::Ramcaches /Common/webacceleration Host: 192.168.102.62 URI : / -------------------------------------- Source Slot/TMM 1/1 Owner Slot/TMM 1/1 Rank 1 Size (bytes) 3545 Hits 5 Received 2017-11-30 22:16:47 Last Sent 2017-11-30 22:56:33 Expires 2017-11-30 23:16:47 Vary Type encoding Vary Count 1 Vary User Agent none Vary Encoding gzip,deflate Again, if you have AAM licensed, you can provision it and then additional fields will be shown in the webacceleration profile above to allow for an acceleration policy to be applied against your virtual server. Resources RFC 2616 - The standard fine print. Things Caches Do- Excellent napkin diagrams that provide simple explanations of caching operations. Caching Tutorial - Comprehensive walk through of caching. HTTP Caching - Brief but informative look at caching from a webdev perspective. HTTP Caching - Google develops page with examples, flowcharts, and advice on caching strategies. Project Acceleration - Our 10 part series on web acceleration technology available on the BIG-IP platform in LTM and/or AAM modules. Solution K5157 - BIG-IP caching and the Vary header Make Your Cache Work For You - Article by Dawn Parzych here on DevCentral on tuning techniques
BIG-IP : deleted data-group/file contents are re-appearing in re-created data-group/file of same name
f5 BIG-IP LTM VE v11.4.0 on ESXi Does BIG-IP somewhere retain contents of deleted data-files - perhaps in a hidden cache file or a database ? Consider the following sequence : Via BIG-IP browser admin , I delete a data-group and then its related data-file. When I peruse BIG-IP's data dirs, the corresponding data-file is no longer present : /config/filestore/files_d/Common_d/data_group_d/:Common:test_data_file_57958_1 This is as expected. Also not present are any other data-files with names of the form : /:Common:test_data_file_* This is also as expected. Next via the iControl API I create a brand new data-group/file of same name test_data_file Via browser admin, I open the newly created data-file, and I'm very surprised to see remnants of the previous deleted data-file’s data ( at the top of the file ), along with some, but not all, of the data I supplied in the new external data-file ( the one that was pointed to with the Browse button during the Create sequence ). This is completely unexpected. Really weird. Somehow BIG-IP is remembering the contents of a deleted data-file and then co-mingling that data with the new data supplied for a new data-file of same name.BIG-IP : iControl LocalLBDataGroupFile.set_local_path()
F5 BIG-IP LTM VE v11.4.0 on ESXi iControl re-cache data-group operation : LocalLBDataGroupFile.set_local_path() For a live prod BIG-IP cluster with a VIP iRule that is actively reading data from the data-group , is the above considered a risky operation ? e.g. attempt live-swap of data-group's data-file, fails due to locks or other systems-level issues, data-group now unavailable to iRule I've attempted live-update of a data-file's contents via BIG-IP browser admin ( copy/paste new contents and click “Update” ) and seen the corresponding data-group become unavailable to the iRule. The paranoid approach is to create a new data-group/file and a copy of the iRule modified to point to this new data-group , and then in the VIP’s iRule list swap old/new iRules – so that never actually update a “live” data-group. So now I am concerned about performing similar operation via iControl LocalLBDataGroupFile.set_local_path() –- although apparently this API is not actually live-updating a cached data-file but rather re-pointing data-group to a new cached data-file ?RAM Cache and POST Requests
Is it possible to store responses to POST requests in RAM Cache using the URI and body as keys? Let's say I have a resource /deals that consumes a json body containing details of a product and returns the available deals for such product. This request doesn't modify any data in my backend. Should I use an IRule to do this? Thanks in advance!F5-RAMcache cache only when the cache headers is present
Hello, I trying to configure the F5 devices to enable cache only when the cache headers is present and caching the time specified in the headers. After done some test I can see the objects without cache headers in the backend are cached with randomly time-to-be-cached (I'm sure is not random but I don't know the algorithm applied) Do anybody how to configure RAMCache to only cache the object when the cache headers is present? In all my tests the field Ignore Headers is set to "none" I like share my lab and test, all of them test in 8950 with 10.2.4 version. http profile applied profile http STATIC-HTTP { defaults from http ... ramcache enable ramcache size 512mb ramcache max entries 10000 ramcache min object size 512 ramcache max object size 102400 ramcache ignore client cache control all ramcache aging rate 9 ramcache insert age header enable ramcache uri exclude "/someobject.gif" ramcache uri include none ramcache uri pinned none ... } F5 runtime memory - tmsh show /ltm profile ramcache STATIC-HTTP .... Host: www.domain.com URI : /file.html -------------------------------------- Source Slot/TMM 0/7 Owner Slot/TMM 0/0 Rank 1 Size (bytes) 274 Hits 0 Received 2015-07-15 06:11:04 Last Sent 2015-07-15 06:11:04 Expires 2015-07-15 06:39:24 Vary Type none Vary Count 1 Vary User Agent none Vary Encoding none Total records returned: 2 Request to F5 - 2 requests, the second one with the origin content changed osmc@osmc:~$ curl --user-agent t7 -H"Host: www.domain.com http://1.2.3.4/file.html -IXGET HTTP/1.1 200 OK Date: Wed, 15 Jul 2015 06:11:04 GMT Server: Apache Last-Modified: Wed, 15 Jul 2015 05:56:54 GMT ETag: "b-51ae39f32c30d" Accept-Ranges: bytes Content-Length: 11 Keep-Alive: timeout=5, max=100 Connection: Keep-Alive Content-Type: text/html osmc@osmc:~$ curl --user-agent t7 -H"Host: www.domain.com http://1.2.3.4/file.html -IXGET HTTP/1.1 200 OK Server: Apache Last-Modified: Wed, 15 Jul 2015 05:56:54 GMT ETag: "b-51ae39f32c30d" Accept-Ranges: bytes Keep-Alive: timeout=5, max=100 Content-Type: text/html Connection: Keep-Alive Date: Wed, 15 Jul 2015 06:11:48 GMT Age: 44 Content-Length: 11 Requests to backend : 2 GETs with apache in foreground and changing the content requested curl -IXGET -H"Host: www.domain.com" http://apacheX/file.html HTTP/1.1 200 OK Date: Wed, 15 Jul 2015 06:11:21 GMT Server: Apache Last-Modified: Wed, 15 Jul 2015 05:56:54 GMT ETag: "b-51ae39f32c30d" Accept-Ranges: bytes Content-Length: 11 Content-Type: text/html 1.2.3.4 vhostX - [15/Jul/2015:08:11:37 +0200] "GET /file.html HTTP/1.1" 200 11 "-" "curl/7.19.5 (ostype) libcurl/7.19.5 OpenSSL/0.9.7d zlib/1.2.3" www.domain.com "-" "-" 1486 date +%s > file.html && cat file.html 1436940694 curl -IXGET -H"Host: www.domain.com" http://apacheX/file.html HTTP/1.1 200 OK Date: Wed, 15 Jul 2015 06:11:37 GMT Server: Apache Last-Modified: Wed, 15 Jul 2015 06:11:34 GMT ETag: "b-51ae3d3a72c54" Accept-Ranges: bytes Content-Length: 11 Content-Type: text/html 1.2.3.4 vhostX - [15/Jul/2015:08:11:37 +0200] "GET /file.html HTTP/1.1" 200 11 "-" "curl/7.19.5 (ostype) libcurl/7.19.5 OpenSSL/0.9.7d zlib/1.2.3" www.domain.com "-" "-" 1486
Bypass caching when a cookie matching a pattern is present
We have created an iRule which should disable caching for any request containing a cookie matching a pattern (starting with SESS). It seems like all the rules we have tried have no effect. When caching is enabled for the pool, requests are always cached. Here is the latest rule we have: when HTTP_REQUEST { set c_cookies [HTTP::cookie names] if {[lsearch -regexp $c_cookies "SESS*"]} { CACHE::disable } } Any ideas on why this wouldn't be working? Also, I'm curious if F5's respect the HTTP Cache-Control max-age header.
F5 LTM appears to be overwriting the cache-control response headers
BIG-IP LTM v15.1.4 When accessing our website through the F5 (VIP), the cache-control response headers are not honoring the values returned by the member servers in the Pool. When accessing the webservers directly (not through the F5) the cache-control header values are correct. INCORRECT HEADERS = cache-control: private CORRECT HEADERS = cache-control: no-cache, no-store We do not have any iRules modifying this header, we are not using Web Application Proxy (WAP), Web Acceleration, etc.Make Your Cache Work For You
One of the questions we frequently get from the field and customers is how to appropriately tune the profile for caching. There are lots of settings in the profile and a mis-configuration can actually cause some pretty adverse effects, so getting the settings tuned properly is highly recommended. Of course the answer to this question is my go-to response ‘It depends.’ I am sure many people have gotten tired of always hearing the same answer for every question, but there is no one size fits all answer to this question. The natural follow on question is “What does it depend on?” Here I can help you with more details. First are you trying to tune caching for RAM cache (AKA Fast cache) or are you trying to tune for Application Acceleration Manager (AAM)? The settings in the profile will perform differently for each of the caches. How do you determine which objects are cacheable and for how long? RAM Cache as the name implies is based entirely on RAM memory and is available with every BIG-IP LTM. AAM’s cache on the other hand uses both RAM memory and disk for storing objects. How the two determine which objects to cache and for how long differs. AAM decides if an object is cacheable based on the policy associated with the application assigned to the profile. Filters are then applied based on object size, “Responses Cached” and Profile settings. How long an object is cached for is then determined by the lifetime settings within the policy. RAM Cache determines if an object is cacheable and for how long based on the configuration within the profile. The settings are the same for all object types there is no per-object setting as exists with AAM. This profile can control both AAM and RAM Cache, although the settings mean different things depending on which you are configuring for. The table below outlines the differences Table 1 highlights the differences between how decisions on caching are made. Setting RAM Cache AAM Cache Cache Size Maximum amount of space that can be used per profile. No borrowing occurs. Minimum amount of space that is dedicated to the profile, borrowing will occur if resources are available. Max Entries Maximum number of objects that can be stored Number of references that are stored for objects in the resource and entity cache. A reference to an object can be evicted from the resource cache but the item still exists in cache and can be served. Responses served from cache may be slightly delayed in these circumstances, but requests will not be proxied to the origin web servers. How long objects are cached for Fixed for all objects based on the max-age setting in the acceleration profile Configurable on a per object or object type basis in the acceleration policy Determination if an object is cacheable Based on configuration in the acceleration profile Based on the acceleration policy responses cached and proxy settings along with the object size setting from the acceleration profile. How much space can be used for caching? The maximum amount of space available for caching is half of the RAM a TMM process has been allocated. Depending on which platform you are using will impact how much space is available for caching. RAM is used for smaller objects and disk is used for larger objects. The maximum amount of space, both memory and disk) that is available for caching with AAM is up to 256 GB per profile, if resources are available. This does NOT mean you should set the size on all profiles to 256 GB. AAM will borrow if space is available. The trick is figuring out what the initial value should be. The following provides some guidelines on how to calculate this initial value. Calculating the ideal cache size The initial set of variables to care about regarding the cache size: OBJECT_SIZE and lifetime settings. Of course, the values of these variables are going to depend (there’s that pesky word again) on the application, the application content, the traffic patterns, etc. The more unique cacheable objects the application may require a larger cache to run faster, however the frequency of access for those objects, if it's low, may make a large cache to be a waste of space since the objects expire in the cache before the next request needs them based on the lifetime, plus cache latency introduced by the high number of records. See it depends. When the cache is full, AAM will evict the entry that is deemed less important, in order to make room for a new one, resulting in cache misses if the number of popular entities is higher than what the cache can accommodate. Lifetime settings have meaning here again, since it could be the case where having a high age value forces the cache to keep on rotating (evicting) still valid content. The main goal should be to minimize evictions and maximize the load savings on the origin web servers. Other "external factors", that dictate amount of memory/disk space available for caching in AAM are: · Hardware specs. · Number of applications running on that device. · Other modules running in the BIG-IP. As I said in the beginning and you can now see this depends on a number of variables, there's no hard answer that applies to all scenarios. Knowing the specifics of the application makes setting the values easier, however if you don’t know the specifics here are some general guidelines on setting the values-: · Min/Max Object Size: Knowing the distribution of object sizes can help determine what these values could be. If your site is made up of mostly GIFs setting a minimum object size of 10Kb could result in the majority of the objects not being cached. Similarly if your objects are mostly flash files and the maximum object size was set to 100 Kb not many items would be cached. Minimum values of 2-4Kb and maximum values of 1MB are good starting points for these settings · Aging/Lifetime settings: How long should content be cached for is often times a business decision. AAM uses default lifetimes of 4 hours for static content such as images and includes. This means an object will not be revalidated for 4 hours, in most instances this is good. Altering this would determine on how often objects are updated and how long it is safe to serve stale content. In most businesses it is rare for an object to be edited frequently. Yes, new objects and content will be added but the same exact file will likely not change. Take a social site like LinkedIn for example – people are constantly changing their profiles, posting articles, and adding content, but much of the content such as icons and JS files stays the same. The last modified dates of content on my LinkedIn home page range from November 2012 – today. With only a few objects from today. Having a cache serve the objects for 4 hours is relatively safe. · Cache size: The cache-size value for the LTM web-acceleration profile should be set to a "trivial" value based on the content type. A good starting point could be the default value of 100MB, however if your site serves a lot of heavy images maybe a larger than default value should be used. Remember AAM will borrow space if needed so there is no need to set this to 100 GB. A value between 100-500MB is likely a good starting point. The trick here is making sure the space isn’t over or under utilized (more on this below). · Number of entries: This should not be set to the total number of objects on the application but rather calculated based on the size of the cache above in either of the following ways: 1) If all content is of primarily a single object type such as images, you can calculate based on the average object size. According to HttpArchive the average image size is 19KB. If you set the cache size to be 100 MB then the max entries could be calculated using the following formula: Cache size / average object size = Max entries 102400/19 = 5389 I would suggest rounding up to pad slightly to a value of 6000. 2) Now not all caches will cache the same exact type of object there will be objects of varying sizes and content types so an alternative way of calculating the max entries # of HTML pages * average # of objects per page = Max entries HttpArchive reports that the average number of objects on a page is 95 and the average number of requests across a single domain is 51. Why the discrepancy and which number to use? With domain sharding and third party content the requests will not all come from a single FQDN. For the purpose of this calculation we are concerned with the objects that are being served from the origin servers no the third party content so I will choose the lower of the numbers. Sadly there is not a metric for the average number of pages if you have access to that number use it otherwise you will have to guess. For the purpose of this example I am going with a nice round number of 300 pages. 300 * 51 = 15300 That’s a lot of objects and honestly is probably too high but we’re not done calculating yet. We assumed that every page will be downloading 51 unique objects from cache, this is not the case. There are likely common items on the pages js, css, images which will be getting served from the browser’s cache and some pages which are only accessed once in a blue moon, it would be safe to estimate that 50-75% of the objects will be getting served from caching resulting in a total of 7650-11475. A number within this range would be a good starting point. There is a bit of trial and error that goes into configuring the settings. With the above guidance and the process below it becomes a bit easier to narrow in on the best settings. 1.- Set the cache values to a seed value as described above and evaluate. 2.- Let the Application receive the traffic it is expected to receive normally. 3.- Monitor the cache stats: Via TMSH on box $ tmsh show ltm profile web-acceleration Or the TMCTL version which provides the output in csv for scripting analysis & parsing $ tmctl profile_webacceleration_jail_stat For example: tmctl -c profile_webacceleration_jail_stat | grep | grep And look for cache_size and cache_evictions. You can run the following (just put the appropriate WEB_ACCEL_PROFILE_NAME and VIRTUAL_SERVER_NAME) to get the simplified table: % cut_fields=`tmctl -c profile_webacceleration_jail_stat | head -1 | awk 'BEGIN{FS=","; fields="name,vs_name,cache_size,cache_evictions"; split(fields,sfx,","); for (x in sfx) sf[sfx[x]] = sfx[x]; cut_fields=""} { for (i=1; i<=NF; ++i) { if ($i in sf ) cut_fields=cut_fields i"," } } END{ print cut_fields }'`; echo ; echo 'Stats table:' ; tmctl -c profile_webacceleration_jail_stat | head -1 | cut -d ',' -f $cut_fields ; tmctl -c profile_webacceleration_jail_stat | grep WEB_ACCEL_PROFILE_NAME | grep VIRTUAL_SERVER_NAME | cut -d ',' -f $cut_fields; echo Like: % cut_fields=`tmctl -c profile_webacceleration_jail_stat | head -1 | awk 'BEGIN{FS=","; fields="name,vs_name,cache_size,cache_evictions"; split(fields,sfx,","); for (x in sfx) sf[sfx[x]] = sfx[x]; cut_fields=""} { for (i=1; i<=NF; ++i) { if ($i in sf ) cut_fields=cut_fields i"," } } END{ print cut_fields }'`; echo ; echo 'Stats table:' ; tmctl -c profile_webacceleration_jail_stat | head -1 | cut -d ',' -f $cut_fields ; tmctl -c profile_webacceleration_jail_stat | grep webacceleration | grep _listener | cut -d ',' -f $cut_fields; echo This command will output the cache size at that moment, and the cache evictions (the number of objects that were pushed out of the cache to make room for new objects). In the example below the cache is empty and as a result there are no evictions. 4.- Given that applications and traffic patterns are fluid and constantly changing it is recommended to periodically monitor the cache size and store the data in a table to view trends over time. If the maximum cache size is reached frequently or there is a high number of cache evictions then adjusting the cache size would be recommended. On the other hand, if you are barely reaching half the value for the cache size and there are no evictions, consider reducing the setting for a more efficient use of resources. Maximizing the cache hits, highly depends on the traffic pattern. A pattern that is conducive to caching depends on having a subset of documents out of the entire document space that are highly popular, and a long tail of less popular documents. Ideally we have enough space to fit all the highly popular documents. If not, then whatever can fit in becomes the cacheable popular content and we have to live with it. As cache pressure rears its head, we throw out a document based on a calculated weight that is derived from some of the parameters AAM to pick a document that has been configured as less important to throw out when under pressure. An important observation here, note that the more objects cached, the greater the time to first byte, so if latency is mentioned as something more important than OWS off-load, you should take note of that. Look carefully at the traffic. Any content produced by programs or scripts, or that require database accesses may not be useful to cache. If it is useful, a select sub-set of very low recency, high hit count, highly ephemeral objects should be marked as memory only. A very big thank you to my following coworkers Eswar Bala, Sergio Ligregni, Matt Miller and John Stevens for contributing to this article.
