It's easy to build complex and dynamic content using Drupal. But a little careless, you will pay the price for this easy. Complex database queries and costly calculations can lead to page performance problems when users view certain complex and dynamic pages.
One solution is to turn on page caching in the DRUAPL background page. When the page cache is turned on, you can significantly reduce the number of database queries on some pages to improve page performance. However, this has some limitations, that is, page caching is only valid for anonymous users. The corresponding login user will take effect.
Gradually, you may analyze your own written code to find out the data out of the query hotspots for cache optimization. Fortunately, Drupal already has some caching APIs built in, and if you follow some of the rules below, it's easier to optimize your code.
Basic Rules:
rule: Do not calculate two times if the result of the calculation can be reused or stored.
The following simple example is used to illustrate this situation.
1 2 3 4 5 6 7 |
function My_module_function () {$my _data = &drupal_static (__function__); if (!isset ($my _data)) {//writes some high-cost calculation logic here and assigns the result to the $my_data variable. } return $my _data; } |
Understanding the above code requires a certain basic knowledge of PHP.
The first thing to know is that PHP has a variable type that is a static variable. The Drupal_static function is actually the centralized management of static variables.
Next is the function of the "&" symbol, this is the value of the address. In this case, any changes to the $my_data variable will be changed to &drupal_static (__function__) accordingly.
This two-point understanding and then look at the logic above, found that although there is only one if judgment, but in fact, this code is very subtle.
Advanced : Use Drupal's cache function.
in the above code, the data for a static variable will only be valid during a single page load. If the page is re-accessed, the calculation of the data is re-evaluated. This means that the data cached by the static variable is temporary and not stored for long periods of time. The following code demonstrates how to store the data of a complex computational result in a Drupal cache table for long-term storage purposes.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
Function my_module_function () { $my _data = &drupal_static (__FUNCTION__); if (!isset ($my _data)) { if ($cache = cache_get (' My _module_data ') { $my _data = $cache->data; } else { //writes some high-cost computational logic here and assigns the result to $ The My_data variable. //the results of the calculations are saved to the cache table here. cache_set (' my_module_data ', $my _data, ' cache '); } return $my _data; } |
The above example, combined with cache_set and cache_get, caches the computed result data in the Drupal cache table, requiring complex computations at the first execution, but the data contents are read directly from the cache table the second time the code is executed. To avoid complex computational overhead or database queries, there is a time to improve the efficiency of code execution.
Cache Data Updates
What if the cache data set using the Cache_set () method expires? By default, the cache for Cache_set settings is stored in the database until you call the Cache_clear_all () function to force empty the cache (if the Admin_menu module is installed, use the admin The empty cache feature provided by menu also clears the cache of the caches table.
If your data is a relatively fragmented update, you can call Cache_clear_ every time the data is updated All (' My_module_data ', ' cache ') updates the cached data. If you are storing some regular pieces of data, you can flush the cache by using wildcards in the following way.
1 |
Cache_clear_all (' My_module ', ' cache ', TRUE); |
This way, all caches starting with my_module are emptied.
If your cache expiration time is regular and predictable, you can try using the following method to set the expiration time for the cache.
1 |
Cache_set (' my_module_data ', $my _data, ' cache ', time () + 3600); |
The last parameter is the UNIX timestamp, which indicates the expiration time of the cache. In this example, the slow presence setting expires after one hours, and the data in the cache is automatically discarded.
Customizing your own cache tables
in the above code presentation process, if you are careful, you will find the third parameter of the Cache_set () function "cache", which is actually the name of the data table representing the cache. If you need to use a large number of caches, it is a good idea to use a separate data table to store the cached data, which helps speed up the data query. The famous Views module uses this technique to implement its cache control strategy.
The simplest and most drupal way to customize a custom cache table is to execute Hook_schema () in the module's install file. The following are examples:
1 2 3 4 |
Function mymodule_schema () { $schema [' Cache_mymodule '] = drupal_get_schema_ Unprocessed (' System ', ' cache '); return $schema; } |
The drupal_get_schema_unprocessed (' System ', ' cache ') in the above function is used to get the definition of Drupal default cache table structure for use by the Cache_mymodule table.
If you want to squeeze the performance of the server thoroughly, simply add a small amount of code to the settings.php file, and you can have the cache system called by Drupal Cache_set,cache_get replaced with other caching systems. For example, the popular memcache (memory-based cache, very efficient), APC (file-based caching), and so on. As long as you use the standard Drupal cache function, you do not need to modify your code even if you change the caching system.
some points to note:
1: Do not cache for caching. For example, query a result from the database, write a result to the database, these are very light operations, there is no need to use the cache. It is recommended to use the Devel module to find code performance bottlenecks and to optimize them accordingly.
2: The data that caches the number of table deposits is BLOB type, do not do join query with cache table.
3: Remember that the data in the cache is not permanently stored. Any code that calls Cache_clear_all will empty the cache. Therefore, data obtained by repeated computations cannot be stored in the cache table.
go ahead, you drupalor!
Now, if you read this article carefully and digest it, congratulations: you have mastered a tool that accelerates your code! Go ahead and continue to optimize!
Drupal 7 cache/Cache Getting Started Guide