why this cache is not working with me ?
Posted: January 16th, 2012, 4:44 pmhi i installed this to my article directory to be able to specially auto cache actually when i visit qc-l-autocache log file i can see page name ever 5 minutes that makes it works but each page still opened 5-6 second and when i see source code i cant see any mark related quick cache is there anybody i can get help ? thank you
+-
-Quick Cache ( On/Off )
Quick Caching Enabled?
You can turn caching On/Off at any time you like. It is recommended that you turn it On. This really is the only option that you need to enable. All of the other options below, are for web developers only, and are NOT required; because the defaults will work just fine. In other words, just turn Quick Cache on here, and then skip all the way down to the very bottom and click Save
Caching Enabled?
Quick Cache improves speed & performance!
-Internal Debugging
Enable Internal Debugging For Quick Cache?
This option is reserved for future implementation. There is already a built-in debugging system for Quick Cache that stays on at all times. Every file it caches and/or serves up will include a comment line or two at the very bottom of the file. Once Quick Cache is enabled you can simply (right-click -> View Source) on your site and look for these to appear. Quick Cache will also report major problems through this method. In the future, additional debugging routines will be added and this option will be used at that time for additional fine-tuning.
Cache Debugging:
Recommended setting ( False ).
-Logged In Users
Don't Cache Pages For Logged In Users?
It is best to leave this set to True at all times. Most visitors are NOT logged in, so this does not hurt performance at all Also, this setting includes some users who AREN'T actually logged into the system, but who HAVE authored comments recently. This way comment authors will be able to see updates to the spool immediately. In other words, Quick Cache thinks of a comment author as a logged in user, even though technically they are not.
Login Sessions:
Recommended setting ( True ).
-GET Requests
Don't Cache Query String GET Requests?
This should almost always be set to True, unless you're using unfriendly Permalinks on your site. In other words, if all of your URLs contain a query string ( /?something=something ), you ARE using unfriendly Permalinks, and you should update your Permalink options in WordPress® immediately, because that also optimizes your site for search engines. That being said, if you really want to use unfriendly Permalinks, and only if you're using unfriendly Permalinks, you should set this to False; and don't worry too much, the sky won't fall on your head It should also be noted that POST requests ( forms with method="POST" ) are always excluded from the cache, which is the way it should be. POST requests should never be cached. CLI requests are also excluded from the cache. A CLI request is one that comes from the command line; commonly used by cron jobs and other automated routines.
* Advanced Tip: If you are NOT caching GET requests ( recommended ), but you do want to allow some special URLs that include query string parameters to be cached; you can add this special parameter to your URL &qcAC=1 to tell Quick Cache that it is OK to cache that particular URL, even though it contains query string arguments.
Query Strings:
Recommended setting ( True ).
-Client-Side Cache
Allow Double-Caching In The Client-Side Browser?
It is best to leave this set to False, particularly if you have users logging in and out a lot. Quick Cache optimizes everything through its ability to communicate with a browser using PHP. If you allow the browser to (cache) the caching system itself, then you are momentarily losing control over whether a cached version will be served or not. We say momentary, because the cached version will eventually expire on its own anyway. This is one major difference between Quick Cache and the original Super Cache plugin. Super Cache allows sort of a double-cache, which really is not very practical, and becomes quite confusing to site owners that spend hours testing & tweaking. All of that being said, if all you care about is blazing fast speed, and you don't update your site that often, you can safely set this to True, and see how you like it.
* Advanced Tip: If you have Double-Caching turned OFF ( recommended ), but you do want to allow some special URLs to be cached by the browser; you can add this special parameter to your URL &qcABC=1. That tells Quick Cache that it's OK for the browser to cache that particular URL, even though you have it disabled for all others. In other words, the qcABC=1 parameter will prevent Quick Cache from sending no-cache headers to the browser.
Browser Cache:
Recommended setting ( False ).
-Cache Expiration Time
Set The Expiration Time On Quick Cache Files?
If you don't update your site much, you could set this to 1 week ( 604800 seconds ) and optimize everything even further. The longer the Cache Expiration Time is, the greater your performance gain. Alternatively, the shorter the Expiration Time, the fresher everything will remain on your site. 3600 ( which is 1 hour ) is the recommended Expiration Time; it's a good middle ground. That being said, you could set this to just 60 seconds, and you would still see huge differences in speed and performance.
Cache Expiration Time ( in seconds ):
Recommended setting ( 3600 ).
-Dynamic Cache Pruning
Enable Dynamic Cache Pruning Routines?
So let's summarize things here and review your configuration thus far. There is an automatic expiration system ( the Garbage Collector ), which runs through WordPress® behind-the-scenes, according to your Expiration setting. Then, there is also a built-in Expiration Time on existing files, which is checked before any cache file is served up; this also uses your Expiration setting. So... what happens if you're working on your site, and you update a Post or a Page? Do visitors have to wait an hour before they see these changes? Or should they see changes like this automatically?
That is where this configuration option comes in. Whenever you update a Post or a Page, Quick Cache can automatically Prune that particular file from the cache, so it instantly becomes fresh again. Otherwise, your visitors would need to wait for the previous cached version to expire. If you'd like Quick Cache to handle this for you, set this option to Single. If you want Quick Cache to completely reset ( purge all cache files ) when this happens; and be triggered on other actions too — like if you rename a category or add links, set this to All. If you don't want any of this, and you just want blazing fast speed at all times, set this to None.
Dynamic Cache Pruning Option:
Recommended setting ( Single, or Single + Front Page ).
-No-Cache URI Patterns
Don't Cache These Special URI Patterns?
Sometimes there are special cases where a particular file, or a particular group of files, should never be cached. This is where you will enter those if you need to. Searches are performed against the REQUEST_URI ( case sensitive ). So don't put in full URLs here, just word fragments found in the file path is all you need, excluding the http:// and the domain name. Wildcards and other regex patterns are not supported here; so you don't need to escape special characters or anything. Please see the examples below for more information.
Don't Cache These URI Patterns:
One per line please... ( these ARE case sensitive )
Do NOT include a leading http:// or your domain name. Let's use this example URL: http://www.example.com/post/example-post. To exclude this URL, you would put this line into the field above: /post/example-post. Or you could also just put in a small fragment, like: example- and that would exclude any URI containing that word fragment.
-No-Cache Referrer Patterns
Don't Cache These Special Referrer Patterns?
Sometimes there are special cases where a particular referring URL ( or referring domain ) that sends you traffic; or even a particular group of referring URLs or domains that send you traffic; should result in a page being loaded on your site that is NOT a cached version. This is where you will enter those if you need to. Searches are performed against the HTTP_REFERER ( case sensitive ). Wildcards and other regex patterns are not supported here; so you don't need to escape special characters or anything. Please see the examples below for more information.
Don't Cache These Referrer Patterns:
One per line please... ( these ARE case sensitive )
Let's use this example URL: http://www.referring-domain.com/?q=search+terms. To exclude this referring URL, you could put this line into the field above: www.referring-domain.com. Or you could also just put in a small fragment, like: q= and that would exclude any referrer containing that word fragment.
-No-Cache User-Agent Patterns
Don't Cache These User-Agent Patterns?
If your site has been designed to support mobile devices through special detection scripting, you might want to disable caching for those devices here. Searches are performed against the HTTP_USER_AGENT string ( case insensitive ). Just put in word fragments that you want to look for in the User-Agent string. If a word fragment is found in the User-Agent string, no caching will occur, and only database-driven content will be served up. Wildcards and other regex patterns are not supported in this field; so you don't need to escape special characters or anything.
Another way to deal with this problem, is to use a custom Salt ( that option is down below ). You could use a custom Salt that includes $_SERVER["HTTP_USER_AGENT"]. This would create different cached versions for every different browser, thereby eliminating the need for this option all together. If your site is really large, you might want to think this through. Having a different set of cache files for every different browser could take up lots of disk space, and there are lots of different browsers out there.
Don't Cache These User-Agent Patterns:
One per line please... ( these are NOT case sensitive )
If you wanted to prevent caching on a BlackBerry, iPhones, and Playstation systems:
BlackBerry
Playstation
iPhone
-Mutex File Locking
Maintain Mutex Using Flock() Or A Semaphore?
On high traffic sites with dedicated servers, a Semaphore (sem_get) offers better performance. Unless your hosting provider has suggested otherwise, it is best to leave this set to the more reliable sem_get method. If your system does not support sem_get, Quick Cache will detect that automatically & fall back on the flock method for you. The flock method can be used on any system, so if you have any trouble using Quick Cache, set this to flock for maximum compatibility.
Cloud Computing? If your site is hosted on a Cloud Computing model, such as the Rackspace® Cloud, or (mt) Media Temple; you should set this to flock unless they tell you otherwise.
Mutex Method:
Recommended setting ( Semaphore ).
-MD5 Version Salt
Create An MD5 Version Salt For Quick Cache?
This is for advanced users only. Alright, here goes... Quick Cache stores its cache files using an md5() hash of the HOST/URI that it's caching. If you want to build these hash strings out of something other than just the HOST/URI, you can add a Salt to the mix. So instead of just md5($_SERVER["HTTP_HOST"].$_SERVER["REQUEST_URI"]), you might have md5($_COOKIE["myCookie"].$_SERVER["HTTP_HOST"].$_SERVER["REQUEST_URI"]). This would create multiple versions of each page depending on the value of $_COOKIE["myCookie"]. If $_COOKIE["myCookie"] is empty, then just $_SERVER["HTTP_HOST"].$_SERVER["REQUEST_URI"] are used. So you see, this gives you the ability to dynamically create multiple variations of the cache, and those dynamic variations will be served on subsequent visits.
A Salt can be a single variable like $_COOKIE["myCookie"], or it can be a combination of multiple variables, like $_COOKIE["myCookie"].$_COOKIE["myOtherCookie"]. When using multiple variables, please separate them with a dot, as shown in the example. Experts can use PHP ternary expressions that evaluate into something. For example: ((preg_match("/IPHONE/i", $_SERVER["HTTP_USER_AGENT"])) ? "IPHONES" : ""). This would force a separate version of the cache to be created for iPhone browsers. With this method your possibilities are limitless.
Quick Cache can also be disabled temporarily. If you're a plugin developer, you can define a special constant within your plugin to disable the cache engine at runtime, on a specific page, or in a specific scenario. In your PHP script, do this: define("QUICK_CACHE_ALLOWED", false). Quick Cache is also compatible with: $_SERVER["QUICK_CACHE_ALLOWED"] = false, as well as define("DONOTCACHEPAGE", true), which is backward compatible with the WP Super Cache plugin.
MD5 Version Salt:
md5(.$_SERVER["HTTP_HOST"].$_SERVER["REQUEST_URI"])
You can use Super Globals: $_SERVER, $_GET, $_REQUEST, $_COOKIE, etc. Or Constants defined in wp-config.php. Example: DB_NAME.DB_HOST.$_SERVER["REMOTE_PORT"] ( separate multiple variables with a dot ). Your Salt will be checked for PHP syntax errors. If syntax errors are found, you'll receive a JavaScript alert, after you click Save.
-Sitemap Auto-Caching
XML Sitemap Auto-Caching + Additional URLs
On sites with PHP scripts that are extremely processor intensive, and in some other rare cases; Auto-Caching might be desirable.
After using Quick Cache for awhile ( or any other cache plugin, for that matter ); it becomes obvious, that at some point ( based on your Expiration setting ), Quick Cache has to refresh itself. It does this by ditching its cached version of a page, re-loading the database-driven content for that page, and re-creating the cache with the latest snapshot. This is a never ending Re-generation Cycle, that is directly affected by your Cache Expiration setting.
This Re-generation Cycle, is how Quick Cache keeps everything up-to-date. Understanding this, you can see that 99% of your visitors are going to receive a lightning fast response from your server. However, there will always be around 1% of your visitors, that land on a page for the very first time ( before it's been cached ), or land on a page that needs to have its cache re-generated, because the existing cache has become outdated. We refer to this as ( the first-come / slow-load issue ).
The Auto-Cache Engine, is designed to combat this issue, by taking on the responsibility of being that first visitor to a page that has not yet been cached, or... has an expired cache. The Auto-Cache Engine is powered, in part, by WP-Cron ( already built into the WP® core framework ). It also uses the WP_Http class, which is also built into WordPress® by default.
The Auto-Cache Engine, obtains its list of URLs, to "Auto Cache", from two different sources. It can read your XML Sitemap, and/or a list of specific URLs that you supply. If you supply both sources, it will use both sources collectively, and intuitively. The Auto-Cache engine takes ALL of your other configuration options into consideration, including your Expiration setting, as well as any No-Cache rules.
The Auto-Cache Engine is highly optimized, so that unnecessary visits to each URL are avoided if at all possible. You can further optimize the Auto-Cache Engine, by setting your Cache Expiration to at least 3600. Generally speaking, we suggest an Expiration setting of 86400. As one of its built-in safeguards, the Auto-Cache Engine will NOT run if your Expiration setting is lower than 3600.
Enable The Auto-Cache Engine?
Recommended setting for most sites ( No ).
Auto Cache User-Agent String:
Quick Cache will pretend it is this User-Agent, and auto-append: + Quick Cache ( Auto-Cache Engine )
The Full URL To Your XML Sitemap:
Tip: the Google® XML Sitemaps plugin for WordPress®, will keep this up-to-date automatically
A List Of Additional URLs, to "Auto-Cache" ( one per line ):
Maximum Processes Allowed ( prevents flooding ):
The Auto-Cache Engine is highly optimized. Unnecessary visits to each URL are avoided if at all possible.
A log will be maintained at: /wp-content/cache/qc-l-auto-cache.log
Recommended setting for most sites ( 5 ).
-Deactivation Safeguards
Deactivation Safeguards ( optional, recommended )
By default, Quick Cache will cleanup ( erase ) all of it's Configuration Options when/if you deactivate it from the Plugins Menu in WordPress®. If you would like to Safeguard all of this information, in case Quick Cache is deactivated inadvertently, please choose Yes ( safeguard all Quick Cache data/options ).
Safeguard Quick Cache Data/Options?
Recommended setting: ( Yes, safeguard all data/options )
+-
-Quick Cache ( On/Off )
Quick Caching Enabled?
You can turn caching On/Off at any time you like. It is recommended that you turn it On. This really is the only option that you need to enable. All of the other options below, are for web developers only, and are NOT required; because the defaults will work just fine. In other words, just turn Quick Cache on here, and then skip all the way down to the very bottom and click Save
Caching Enabled?
Quick Cache improves speed & performance!
-Internal Debugging
Enable Internal Debugging For Quick Cache?
This option is reserved for future implementation. There is already a built-in debugging system for Quick Cache that stays on at all times. Every file it caches and/or serves up will include a comment line or two at the very bottom of the file. Once Quick Cache is enabled you can simply (right-click -> View Source) on your site and look for these to appear. Quick Cache will also report major problems through this method. In the future, additional debugging routines will be added and this option will be used at that time for additional fine-tuning.
Cache Debugging:
Recommended setting ( False ).
-Logged In Users
Don't Cache Pages For Logged In Users?
It is best to leave this set to True at all times. Most visitors are NOT logged in, so this does not hurt performance at all
Also, this setting includes some users who AREN'T actually logged into the system, but who HAVE authored comments recently. This way comment authors will be able to see updates to the spool immediately. In other words, Quick Cache thinks of a comment author as a logged in user, even though technically they are not.Login Sessions:
Recommended setting ( True ).
-GET Requests
Don't Cache Query String GET Requests?
This should almost always be set to True, unless you're using unfriendly Permalinks on your site. In other words, if all of your URLs contain a query string ( /?something=something ), you ARE using unfriendly Permalinks, and you should update your Permalink options in WordPress® immediately, because that also optimizes your site for search engines. That being said, if you really want to use unfriendly Permalinks, and only if you're using unfriendly Permalinks, you should set this to False; and don't worry too much, the sky won't fall on your head
It should also be noted that POST requests ( forms with method="POST" ) are always excluded from the cache, which is the way it should be. POST requests should never be cached. CLI requests are also excluded from the cache. A CLI request is one that comes from the command line; commonly used by cron jobs and other automated routines.* Advanced Tip: If you are NOT caching GET requests ( recommended ), but you do want to allow some special URLs that include query string parameters to be cached; you can add this special parameter to your URL &qcAC=1 to tell Quick Cache that it is OK to cache that particular URL, even though it contains query string arguments.
Query Strings:
Recommended setting ( True ).
-Client-Side Cache
Allow Double-Caching In The Client-Side Browser?
It is best to leave this set to False, particularly if you have users logging in and out a lot. Quick Cache optimizes everything through its ability to communicate with a browser using PHP. If you allow the browser to (cache) the caching system itself, then you are momentarily losing control over whether a cached version will be served or not. We say momentary, because the cached version will eventually expire on its own anyway. This is one major difference between Quick Cache and the original Super Cache plugin. Super Cache allows sort of a double-cache, which really is not very practical, and becomes quite confusing to site owners that spend hours testing & tweaking. All of that being said, if all you care about is blazing fast speed, and you don't update your site that often, you can safely set this to True, and see how you like it.
* Advanced Tip: If you have Double-Caching turned OFF ( recommended ), but you do want to allow some special URLs to be cached by the browser; you can add this special parameter to your URL &qcABC=1. That tells Quick Cache that it's OK for the browser to cache that particular URL, even though you have it disabled for all others. In other words, the qcABC=1 parameter will prevent Quick Cache from sending no-cache headers to the browser.
Browser Cache:
Recommended setting ( False ).
-Cache Expiration Time
Set The Expiration Time On Quick Cache Files?
If you don't update your site much, you could set this to 1 week ( 604800 seconds ) and optimize everything even further. The longer the Cache Expiration Time is, the greater your performance gain. Alternatively, the shorter the Expiration Time, the fresher everything will remain on your site. 3600 ( which is 1 hour ) is the recommended Expiration Time; it's a good middle ground. That being said, you could set this to just 60 seconds, and you would still see huge differences in speed and performance.
Cache Expiration Time ( in seconds ):
Recommended setting ( 3600 ).
-Dynamic Cache Pruning
Enable Dynamic Cache Pruning Routines?
So let's summarize things here and review your configuration thus far. There is an automatic expiration system ( the Garbage Collector ), which runs through WordPress® behind-the-scenes, according to your Expiration setting. Then, there is also a built-in Expiration Time on existing files, which is checked before any cache file is served up; this also uses your Expiration setting. So... what happens if you're working on your site, and you update a Post or a Page? Do visitors have to wait an hour before they see these changes? Or should they see changes like this automatically?
That is where this configuration option comes in. Whenever you update a Post or a Page, Quick Cache can automatically Prune that particular file from the cache, so it instantly becomes fresh again. Otherwise, your visitors would need to wait for the previous cached version to expire. If you'd like Quick Cache to handle this for you, set this option to Single. If you want Quick Cache to completely reset ( purge all cache files ) when this happens; and be triggered on other actions too — like if you rename a category or add links, set this to All. If you don't want any of this, and you just want blazing fast speed at all times, set this to None.
Dynamic Cache Pruning Option:
Recommended setting ( Single, or Single + Front Page ).
-No-Cache URI Patterns
Don't Cache These Special URI Patterns?
Sometimes there are special cases where a particular file, or a particular group of files, should never be cached. This is where you will enter those if you need to. Searches are performed against the REQUEST_URI ( case sensitive ). So don't put in full URLs here, just word fragments found in the file path is all you need, excluding the http:// and the domain name. Wildcards and other regex patterns are not supported here; so you don't need to escape special characters or anything. Please see the examples below for more information.
Don't Cache These URI Patterns:
One per line please... ( these ARE case sensitive )
Do NOT include a leading http:// or your domain name. Let's use this example URL: http://www.example.com/post/example-post. To exclude this URL, you would put this line into the field above: /post/example-post. Or you could also just put in a small fragment, like: example- and that would exclude any URI containing that word fragment.
-No-Cache Referrer Patterns
Don't Cache These Special Referrer Patterns?
Sometimes there are special cases where a particular referring URL ( or referring domain ) that sends you traffic; or even a particular group of referring URLs or domains that send you traffic; should result in a page being loaded on your site that is NOT a cached version. This is where you will enter those if you need to. Searches are performed against the HTTP_REFERER ( case sensitive ). Wildcards and other regex patterns are not supported here; so you don't need to escape special characters or anything. Please see the examples below for more information.
Don't Cache These Referrer Patterns:
One per line please... ( these ARE case sensitive )
Let's use this example URL: http://www.referring-domain.com/?q=search+terms. To exclude this referring URL, you could put this line into the field above: www.referring-domain.com. Or you could also just put in a small fragment, like: q= and that would exclude any referrer containing that word fragment.
-No-Cache User-Agent Patterns
Don't Cache These User-Agent Patterns?
If your site has been designed to support mobile devices through special detection scripting, you might want to disable caching for those devices here. Searches are performed against the HTTP_USER_AGENT string ( case insensitive ). Just put in word fragments that you want to look for in the User-Agent string. If a word fragment is found in the User-Agent string, no caching will occur, and only database-driven content will be served up. Wildcards and other regex patterns are not supported in this field; so you don't need to escape special characters or anything.
Another way to deal with this problem, is to use a custom Salt ( that option is down below ). You could use a custom Salt that includes $_SERVER["HTTP_USER_AGENT"]. This would create different cached versions for every different browser, thereby eliminating the need for this option all together. If your site is really large, you might want to think this through. Having a different set of cache files for every different browser could take up lots of disk space, and there are lots of different browsers out there.
Don't Cache These User-Agent Patterns:
One per line please... ( these are NOT case sensitive )
If you wanted to prevent caching on a BlackBerry, iPhones, and Playstation systems:
BlackBerry
Playstation
iPhone
-Mutex File Locking
Maintain Mutex Using Flock() Or A Semaphore?
On high traffic sites with dedicated servers, a Semaphore (sem_get) offers better performance. Unless your hosting provider has suggested otherwise, it is best to leave this set to the more reliable sem_get method. If your system does not support sem_get, Quick Cache will detect that automatically & fall back on the flock method for you. The flock method can be used on any system, so if you have any trouble using Quick Cache, set this to flock for maximum compatibility.
Cloud Computing? If your site is hosted on a Cloud Computing model, such as the Rackspace® Cloud, or (mt) Media Temple; you should set this to flock unless they tell you otherwise.
Mutex Method:
Recommended setting ( Semaphore ).
-MD5 Version Salt
Create An MD5 Version Salt For Quick Cache?
This is for advanced users only. Alright, here goes... Quick Cache stores its cache files using an md5() hash of the HOST/URI that it's caching. If you want to build these hash strings out of something other than just the HOST/URI, you can add a Salt to the mix. So instead of just md5($_SERVER["HTTP_HOST"].$_SERVER["REQUEST_URI"]), you might have md5($_COOKIE["myCookie"].$_SERVER["HTTP_HOST"].$_SERVER["REQUEST_URI"]). This would create multiple versions of each page depending on the value of $_COOKIE["myCookie"]. If $_COOKIE["myCookie"] is empty, then just $_SERVER["HTTP_HOST"].$_SERVER["REQUEST_URI"] are used. So you see, this gives you the ability to dynamically create multiple variations of the cache, and those dynamic variations will be served on subsequent visits.
A Salt can be a single variable like $_COOKIE["myCookie"], or it can be a combination of multiple variables, like $_COOKIE["myCookie"].$_COOKIE["myOtherCookie"]. When using multiple variables, please separate them with a dot, as shown in the example. Experts can use PHP ternary expressions that evaluate into something. For example: ((preg_match("/IPHONE/i", $_SERVER["HTTP_USER_AGENT"])) ? "IPHONES" : ""). This would force a separate version of the cache to be created for iPhone browsers. With this method your possibilities are limitless.
Quick Cache can also be disabled temporarily. If you're a plugin developer, you can define a special constant within your plugin to disable the cache engine at runtime, on a specific page, or in a specific scenario. In your PHP script, do this: define("QUICK_CACHE_ALLOWED", false). Quick Cache is also compatible with: $_SERVER["QUICK_CACHE_ALLOWED"] = false, as well as define("DONOTCACHEPAGE", true), which is backward compatible with the WP Super Cache plugin.
MD5 Version Salt:
md5(.$_SERVER["HTTP_HOST"].$_SERVER["REQUEST_URI"])
You can use Super Globals: $_SERVER, $_GET, $_REQUEST, $_COOKIE, etc. Or Constants defined in wp-config.php. Example: DB_NAME.DB_HOST.$_SERVER["REMOTE_PORT"] ( separate multiple variables with a dot ). Your Salt will be checked for PHP syntax errors. If syntax errors are found, you'll receive a JavaScript alert, after you click Save.
-Sitemap Auto-Caching
XML Sitemap Auto-Caching + Additional URLs
On sites with PHP scripts that are extremely processor intensive, and in some other rare cases; Auto-Caching might be desirable.
After using Quick Cache for awhile ( or any other cache plugin, for that matter ); it becomes obvious, that at some point ( based on your Expiration setting ), Quick Cache has to refresh itself. It does this by ditching its cached version of a page, re-loading the database-driven content for that page, and re-creating the cache with the latest snapshot. This is a never ending Re-generation Cycle, that is directly affected by your Cache Expiration setting.
This Re-generation Cycle, is how Quick Cache keeps everything up-to-date. Understanding this, you can see that 99% of your visitors are going to receive a lightning fast response from your server. However, there will always be around 1% of your visitors, that land on a page for the very first time ( before it's been cached ), or land on a page that needs to have its cache re-generated, because the existing cache has become outdated. We refer to this as ( the first-come / slow-load issue ).
The Auto-Cache Engine, is designed to combat this issue, by taking on the responsibility of being that first visitor to a page that has not yet been cached, or... has an expired cache. The Auto-Cache Engine is powered, in part, by WP-Cron ( already built into the WP® core framework ). It also uses the WP_Http class, which is also built into WordPress® by default.
The Auto-Cache Engine, obtains its list of URLs, to "Auto Cache", from two different sources. It can read your XML Sitemap, and/or a list of specific URLs that you supply. If you supply both sources, it will use both sources collectively, and intuitively. The Auto-Cache engine takes ALL of your other configuration options into consideration, including your Expiration setting, as well as any No-Cache rules.
The Auto-Cache Engine is highly optimized, so that unnecessary visits to each URL are avoided if at all possible. You can further optimize the Auto-Cache Engine, by setting your Cache Expiration to at least 3600. Generally speaking, we suggest an Expiration setting of 86400. As one of its built-in safeguards, the Auto-Cache Engine will NOT run if your Expiration setting is lower than 3600.
Enable The Auto-Cache Engine?
Recommended setting for most sites ( No ).
Auto Cache User-Agent String:
Quick Cache will pretend it is this User-Agent, and auto-append: + Quick Cache ( Auto-Cache Engine )
The Full URL To Your XML Sitemap:
Tip: the Google® XML Sitemaps plugin for WordPress®, will keep this up-to-date automatically
A List Of Additional URLs, to "Auto-Cache" ( one per line ):
Maximum Processes Allowed ( prevents flooding ):
The Auto-Cache Engine is highly optimized. Unnecessary visits to each URL are avoided if at all possible.
A log will be maintained at: /wp-content/cache/qc-l-auto-cache.log
Recommended setting for most sites ( 5 ).
-Deactivation Safeguards
Deactivation Safeguards ( optional, recommended )
By default, Quick Cache will cleanup ( erase ) all of it's Configuration Options when/if you deactivate it from the Plugins Menu in WordPress®. If you would like to Safeguard all of this information, in case Quick Cache is deactivated inadvertently, please choose Yes ( safeguard all Quick Cache data/options ).
Safeguard Quick Cache Data/Options?
Recommended setting: ( Yes, safeguard all data/options )