Differences

This shows you the differences between two versions of the page.

--- v5:userguide:learn_caching:adodb_coding [2016/03/29 00:46] – [The Time-To-Live] mnewnham
+++ v5:userguide:learn_caching:adodb_coding [2016/03/29 04:56] (current) – mnewnham
@@ Line 1: / Line 1: @@
+<- v5:userguide:learn_caching:cache_ttl|Understanding Time-To-Live ^ v5:userguide:userguide_index|List Of Tutorials ^  v5:userguide:learn_caching:cache_problems|Debugging Problems With Caching->
-<- v5:userguide:learn_caching:memcached|Memcached Caching ^ v5:userguide:userguide_index|List Of Tutorials ^  ->
 ~~NOTOC~~
 ====== Using Cached Queries ======
@@ Line 10: / Line 8: @@
 The format of the parameters in the cache methods matches that of the normal methods, except for the fact that the parameters are shifted one entry and the first parameter is always the TTL (Time-To-Live) of the query.
-===== The Time-To-Live =====
-The TTL of the query is the amount of time that the results of a query are cached before the results are re-requested from a database. The following sequence of events occurs:
-  - A query is issued via one of the ADOdb ''cache request'' methods.
-  - ADOdb checks to see if the same query has been requested within the TTL value provided.
-    - Note that a statement can always request a 'fresh' result set by providing a 0 (Zero) value TTL.
-  - If there is a stored resultset available, it uses that.
-  - If there is no result available, or the result is too old, the query is issued to the database, and the resulting recordset is both returned to the requester and stored for later requests.
-===== Determining Appropriate TTL =====
-In real-world applications, the TTL of a query will likely be either extremely short, or extremely long. Take the following examples:
-==== Long TTL ====
-The most common usage for cached queries is returning static data sets, for example a database-provided key-value pair to populate a select list. The permanancy of the data may be such that the TTL of the query requesting it might not need be no more than once per day, in seconds therefore it would be:
-* 60 * 24 =  86400
+<code php>
-==== Short TTL ====
-Determining the appropriate TTL for a short life request is much more difficult. As system design has moved towards real-time response, the TTL for short-life requests has decreased. The critical factor has become how often a recordset is requested, rather than how often the data changes. For example, in a large system where a single specific query is requested 100 times a minute, but is updated regularly might be configured with a TTL of only 60 seconds. On a well configured system, clearly the results of a request like this would likely be cached by the system or server itself, but a heavily loaded server might benefit from the reduction of preparation and issuing of the query from 100 to 1 times per minute.
-If the query itself is complex, or suffers from poor index design, the benefit can be even greater.
 /*
 * look for a cached query with a life of 2400 seconds
 */
 $sql = 'SELECT code,description FROM xref_table';
-$db->cacheExecute(2400,$sql);
+$db->cacheGetAssoc(2400,$sql);
 </code>
-===== Using Debug Mode  =====
-The size of query results that can be cached by the memcached server is limited by server configuration. The default is quite small. If the query is too large, and [[v5:reference:debug|debugging]] is enabled, then an error is displayed.
-  3849805e4e026b9e7c485999a24a95c6 cache failure: Item with such key doesn't exists on the memcached server.
-  (this is a notice and not an error)
-  -----<hr>
-  (mysqli): SELECT * FROM employees
-  -----<hr>
-  Notice: MemcachePool::set(): Server 192.168.0.78 (tcp 11211, udp 0) failed with:
-  SERVER_ERROR object too large for cache
-  (3) in C:\dev\github\mssqlnative-fixes\adodb-memcache.lib.inc.php on line 94
-  Failed to save data at the memcached server!
-  Cache write error
-  PHP Notice:  MemcachePool::set(): Server 192.168.0.78 (tcp 11211, udp 0) failed with:
-  SERVER_ERROR object too large for cache (3)
-  in C:\dev\github\mssqlnative-fixes\adodb-memcache.lib.inc.php on line 94
-ADOdb currently has no mechanism for splitting large queries into smaller chunks.
-{{tag>[memcached cache]}}
+The response from the cache functions is exactly the same as the normal functions.