LiteMage Cache Administration

This page is dedicated to the different functions, tools, and tricks available to administrators in LiteMage Cache.

There are three methods of enabling LiteMage administrative privilege browser commands for your Magento site. The one you choose to use will depend on the mode you would like LiteMage to be in at the time as well as the type of commands you would like access to.

The following are two methods of enabling debug-related browser commands on your Magento site.

All debug-related commands will contain “LITEMAGE_DEBUG”.

By putting LiteMage in debug mode you are giving any IP that can access your site permission to use debug-related browser commands with regard to LiteMage. It is not recommended to do this unless your Magento site is only accessible by you at the time.

To enable Debug Mode, log in to the Magento Admin Panel and navigate to System → Configuration. Under “LITEMAGE CACHE” in the left side menu, click “LiteMage Configuration”. Under “Developer Testing” set Enable Debug to “Yes”.

By enabling LiteMage for certain IPs only, you are giving permission to use debug-related browser commands with regard to LiteMage to those specific IPs as well as disabling LiteMage for all other traffic to your site. This setting can be very useful for debugging.

To enable LiteMage for certain IPs only, log in to the Magento Admin Panel and navigate to System → Configuration. In the left hand side menu under “LITEMAGE CACHE”, click “LiteMage Configuration”. Under “Developer Testing” add the desired IPs to the Enable LiteMage Cache Only for Listed IPs field.

The following method will enable all available browser commands (including debug-related browswer commands).

This is the most direct and least obtrusive way of enabling administrative privilege browser commands for specific IPs. This can be less useful for debugging, as LiteMage will remain enabled for all visitors to your site.

To add your IP to the Admin IPs list, log in to the Magento Admin Panel and navigate to System → Configuration. In the left hand side menu under “LITEMAGE CACHE”, click “LiteMage Configuration”. Under “General Settings” add the desired IPs to the Admin IPs field.

The following is a complete list of LiteMage Administrative privilege browser commands along with their descriptions. You can use these commands (with the proper privileges) by adding them to the end of a LiteMage enabled URL in your browser's address bar.

• ?LITEMAGE_DEBUG=NOCACHE - This command is used for retrieving the current page from the backend, bypassing LiteMage Cache. This is useful for checking the accuracy of the currently cached version of a page.
• ?LITEMAGE_DEBUG=SHOWHOLES - This command is used to display holes punched during the ESI process. This is useful for checking if all private blocks are being properly hole punched by LiteMage.
  For Example:
  
  Note: valueOnly blocks will not be shown.
• ?LITEMAGE_CTRL=PURGE - This command allows you to purge the current page from cache without having to go through the Magento Admin Panel.
• /litemage/admin/purge?tags= - This command is used to purge any page containing a certain item, category, or cms page by ID number. The command should be followed by a comma separated list of tags and ID numbers where the tag can be P(for product), C(for catalog), or G(for cms page), followed by a dot and the desired numeric ID.
  
  For Example: your_site_url/litemage/admin/purge?tags=P.345,C.4,G.1
  
  This is very useful in cases where your Magento database is updated by an external program. In these cases you can use GET with this parameter in a script to automate purging the affected products, categories, or cms pages.
  
  Note: This is not necessary if updating only through the Magento Admin Panel. When a product is saved in the Magento Admin Panel, not only the product page but also all the related category pages will be automatically purged.

Like most caches, LiteMage Cache needs to be periodically cleaned to prevent the cache storage from growing too large. Deleting these files by flushing the cache through Magento could slow down your site and it would instead be preferable to do this cleaning in a separate process. To this end LiteMage will only mark files as “expired” when the cache is flushed instead of deleting them outright. To do the actual cleaning, we have included a cleanlitemage.sh script in the admin/misc directory of your LSWS installation directory.

This script takes from one to three plus input parameters, which are as follows:

• -priv <age_mins> - (Optional) - Determines the maximum age (in minutes) of items stored in the private cache. The default value is 60 minutes. If set, value must be greater than 0.
• -pub <age_mins> - (Optional) - Determines the maximum age (in minutes) of items stored in the public cache. The default value is 0, meaning public cache will not be purged. If set, value must be greater than 10.
• <litemage_cache_dir1> … <litemage_cache_dir9> - (Required) - Specifies one or more LiteMage cache storage directories separated by spaces. Each directory must contain the /priv directory.

Note: The values (in minutes) used for -priv and -pub should be set higher than Default Private Cache TTL (seconds) and Default Public Cache TTL (seconds) in LiteMage's Configuration settings in the Magento Admin Panel. This will ensure that you are only purging expired files.

Tip: Once you have found a combination of settings that keeps your cache size reasonable, you can then include this script in a cron job to automate the process.

In your Magento Admin Panel, at the bottom of the System → Cache Management page, is a section where you can monitor and manage the crawler's status.

Each crawler queue is listed as its own row in the table, sorted ascending based on priority. Included with each crawler listing is:

• Base URL - The URL from which the crawler starts crawling this queue.
• Custom List Path - This is the location of the list of paths the crawler will crawl for this queue. This can be viewed by clicking on the “Details” link for each queue.
• Run Interval (in seconds) - The time interval at which the crawler will run this queue. Refer again to our first example above, Run Interval has a value of 23400 seconds or 6.5 hours meaning that the crawler will crawl this queue every 6.5 hours.
• Store Public TTL (in seconds) - The time interval at which the public cache will be invalidated for this site. The first site above is set so the public cache is purged every 28800 seconds or every 8 hours.
• Generated - The time and date when the crawler queue was last generated.
• Finished - The time and date when the crawler last finished crawling this queue. This only appears if the crawler finished crawling this queue.
• Environment - A listing of all environment varies set for this queue. In the first row above, the varies listed are “-” which represents the default currency, USD, and GBP.
• Current Vary - The vary the crawler is currently crawling, this will remain as the last vary from your Environment list if the crawler finishes this queue.
• Current Position - The current position of the crawler in this queue.
• List Size - The size of the crawler's queue before varies are included.
• Last Query Time - The last time and date a page was crawled in this queue.
• Total Queried - The current total number of pages crawled in this queue including varies. When the crawler completes the queue, this should be equal to the number of varies times List Size. In the first row above, we have 3 varies (default, USD, and GBP). Because the first queue was completely crawled, 534 pages were crawled. 3 varies times 178 pages equals 534 total pages.

A crawler queue can be reset by clicking the corresponding “Reset” link in this section. This will remove values for: Custom List Path, Generated, Finished, List Size, and Last Query Time which will be repopulated when the crawler regenerates the list and crawls it. This will also set Current Position and Total Queried back to zero, starting the queue from the beginning the next time the crawler crawls it.

Note: If, after updating a page, a user wants to refresh the cached copy of this page, they can use the following command in a cron job to refresh the cached copy programmatically:

curl -A "litemage_walker" https://your_url

Refreshing the cache is not the same as invalidating it. When the cached copy is invalidated, the next user to hit the invalidated page will have to wait longer for the page to load as there is no copy to serve from cache. When the cache is refreshed, the cached copy is overwritten with the current version of the page.

The difference between the LiteMage Purge command and the curl command listed above is that the Purge command invalidates the cache for the current page, while the curl command refreshes the cached copy of the given URL.