Jan 01, 2015

Four updates to the FileMaker-based dynamic website cache primer/loader project this week have made it a much more polished and useful tool.

 

Small incremental changes were made to the website cache loader/primer project this week. The changes are documented in more detail on the Github wiki page for this project.

 

Version 1.01

• A default FileMaker theme was applied, making the solution look much more finished.
• A cancel button was added, will terminate any fast or drip cache that might be in progress. Would allow someone making changes to a website cancel a drip cache of all sites so that they could run a fast cache on the modified site.
• Onscreen documentation was added that explains how to use the solution. The goal is that it be so focussed on its task and intuitive that any additional documentation will be minimal.
• Hide condition was added to the fast cache button in the last row of the sites portal. New sites are added by entering the last portal row directly so the fast cache button was always visible, even when it could not possibly be run. This change reduces visual clutter and avoids presenting a non-working option. That was taken one step further – the button is hidden until a site map address has been entered  - entering a site name alone is not enough to reveal the button. If you can't use the button it doesn't exist.

 

Version 1.02

This version added some feedback to the caching process. Three fields were added:

• Total URLs: The total number of pages that the solution will try and retrieve. Calculated using the native FileMaker Pattern Count function as soon as the site map is successfully retrieved.
• Processed URLs: The number of pages that the solution has retrieved. Intended to give the user a sense of the progress and time to completion this number refreshes each time a page is retrieved.
• Percentage: The number of processed urls divided by the number of total urls – expressed the progress as a percentage.

 

Version 1.03

This version added some statistics to help the user make more informed decision about what type of cache job is better in a particular situation.

• Type parameter: The site cache script now looks for "drip" or "fast" as the first parameter and proceeds accordingly. One of the things this accomplishes is letting us keep separate statistics for each job type.
• Elapsed Time: This keeps track of the total time it took to last run each job type.
• Last Ran Timestamp: Records the date/time each job type was completed.

The two values above are only set when the job is completed successfully – it was scripted this way on purpose.

The two job types have different purposes. The drip option is meant to run continually in the background, looping through the site and calling every page at least once a day so that it is always in the cache. The fast cache option is meant to be used when changes are being made to a site and the admin wants to quickly get it loaded into the cache. This is particularly important if they have purged the cache while making changes – this priming solution helps get the site ready for the next visitor.

 

Version 1.04

This version changed the method used to retrieve the web pages. Earlier versions had used the FileMaker web viewer, this version uses the Insert From URL script step. Insert from URL automatically pauses the script until the page contents have been retrieved, the Web Viewer option did not – requiring an arbitrary best guess at a delay script setting. Switching to Insert From URL made the solution much more efficient, it can now prime more than 100 pages in less than one minute.

This version also added a new parameter that allows the user to specify the delay between page requests when in drip cache mode.

 

Each of the updates was minor but by version 1.04 we have a nice looking, intuitive and useful solution. Small changes are the foundation of this project – any changes for the foreseeable future should be implementable in 90 minutes or less.

Related Content