July 13, 2009 at 05:02Drupal Optimization
Introduction
Drupal is a fairly common CMS and this left its mark on it - the basic Drupal delivery is not a ready-made solution for a certain type of site, but the foundation for its creation. There are “assemblies” based on Drupal specialized for certain types of sites, for example: news sites. But such assemblies are currently not widely distributed and poorly supported. In this regard, when creating an Internet site based on the standard Drupal delivery, a large number of ready-made additional modules and themes for Drupal are used, or new modules and themes are developed specifically for the created Internet site. The last step in creating a site is its optimization, which can be conditionally divided into 4 steps:
Built-in Drupal Optimization
1. Disable all unused modules. Since when generating a page before sending it to the user's browser, the code of certain modules can be executed even if the functionality of this module is not used on the site. The processor time of the server will be spent on code execution, which will lead to longer page generation. An example of such a module is Statistics. Instead of statistics generated by this module, you can use the statistics of the service - Google Analytics.
2. When creating the site, we use Drupal version 6, as it better implements internal caching tools. Also, additional modules (Views, Panel, etc.) for Drupal version 6 have implemented effective caching methods. Unfortunately, not all Drupal version 5 modules are implemented for Drupal version 6 (for example, the Sphinx module), we will not forget about this when planning the development of an Internet site. Next, we will consider only Drupal version 6.
3. We’ll carefully consider the options for using modules similar to the CCK (Content Construction Kit), before implementing the plan for creating the site. For example, the simple task of storing thousands of types of products, their names and descriptions in the database of a site is solved with the help of:
When complicating the task using the condition that all types of products should be divided into 10 groups, the problem is solved in two ways. Option one, using a taxonomy:
Option two using CCK:
The main error in solving such problems creates an additional load on the database:
4. We use the built-in caching of Drupal. It allows you to cache information retrieved from the database, as well as information obtained by processing the extracted information from PHP.
Caching of the menu system, filters of input formats, administration variables (for example: site name) and module settings is done automatically. Other caching parameters can be configured on the page: Management -> Performance ( http://www.example.ru/admin/settings/performance ).
On this page you can configure:
Turn on page caching in normal mode. In this mode of page caching, when viewing a page for the first time (by an anonymous, unregistered user in the system), the generated page is saved to the cache. Later, when viewing this page (by an anonymous user), it is not generated again, but is taken from the cache, which greatly speeds up Drupal.
When you enable page caching in the aggressive mode, when generating a page, the loading and unloading of enabled modules is skipped, so some of the modules may work incorrectly or not work at all.
Set the minimum page cache lifetime for anonymous users. This parameter determines how long after caching the page, it checks whether the contents of this page are updated or not. If updated, then the cache of this page is cleared. Those. if the site administrator has changed the content of the page, he will see it immediately, and anonymous users, only after a minimum cache lifetime.
We enable page compression to save the compressed page cache and to transfer the page to the user's browser in a compressed form, if it supports gzip compression. Compression is performed using the zlib library installed as an extension in PHP.
Turn on block caching. The principle of block caching is similar to the principle of page caching. For a super user (the first registered user when installing Drupal, his id is 1), the blocks are never cached.
Turn on CSS and JavaScript file optimization. This will reduce their size and the number of calls to the server when loading pages into the browser. All CSS and JavaScript files are assembled into one (your own file for CSS and your own for JavaScript). Which reduces the number of calls to the server when loading the page.
Optimizing Drupal with Modules
1. Install the Authenticated User Page Caching (Authcache) module, you can download it at the Internet address - http://drupal.org/project/authcache. This module allows you to cache pages for both anonymous users and authenticated (“logged in”) users better than the built-in Drupal caching. When installing this module, you must reconfigure the dynamic content on the pages (for example: displaying the name of an authenticated user).
Authcache maintains a compressed page cache separately for each user or role. The cache is stored in the database or in a third-party caching tool (memcahed, APC, etc.). Cached versions of pages for authenticated users (except for the super-user) are transferred using AJAX, so a very fast page display in the browser is achieved. If the authenticated user has JavaScript disabled in the browser, then he does not receive pages from the cache. On some servers, page loading speed decreases to 1 millisecond.
To install the module:
$ conf ['cache_inc'] = './sites/all/modules/authcache/api/authcache.inc';
$ conf ['authcache'] = array (
'default' => array (
// caching technology - apc, memcache, db, file, eacc or xcache
'engine' => 'db',
// if we use memcached (host: port, e..g, 'localhost: 11211')
'server' => array (),
// if we use memcached shared single process
'shared' => TRUE,
// prefix key cache (for several sites)
'prefix' => '',
// if we use caching on files - specify the path
// to save them
'path'
// static array cache (advanced) // static cache array (extended)
'static' => FALSE,
),
);
In this code, the settings of the Authcache module are set. We indicate that we will store the page cache in the database ('engine' => 'db'), so all other settings do not matter, we leave them unchanged. You can read more about the parameters of this code on the page - http://drupal.org/project/cacherouter (in English).
We enable the Authcache module on the page: Management -> Modules ( http://www.example.ru/admin/build/modules ). After that, we will configure its work on the page: Management -> Performance -> Authcache (http://www.example.ru/admin/settings/performance/authcache ):
We’ll change the settings of the elements on the site’s pages, so that the page for different users belonging to the same role would look the same (i.e., for example: we will forbid users to control the visibility of blocks on the site, if such blocks exist).
We use variables in the themes templates:
You can also familiarize yourself with the example - / sites / all / modules / authcache / modules / authcache_example, which shows how to configure blocks with user content (with user content).
2. If you need to cache pages only for anonymous users (without authenticated users), you can install the Cache Router module. This module is the basis of the Authcache module and caches pages better than Drupal's built-in caching. Download the module at the Internet address - http://drupal.org/project/authcache . After downloading, unpack the module into the / sites / all / modules folder. We enable the Cache Router module on the page: Management -> Modules ( http://www.example.ru/admin/build/modules ). Open the settings.php file (in the / sites / default folder) and add the following code to the beginning of the file before the tag
$ conf ['cache_inc'] = './sites/all/modules/cacherouter/cacherouter.inc';
$ conf ['cacherouter'] = array (
'default' => array (
'engine' => 'db',
'server' => array (),
'shared' => TRUE,
'prefix' => '',
'path' => 'sites / default / files / filecache',
'static' => FALSE,
'fast_cache' => TRUE,
),
);
3. After the implementation of the above actions, the pages of the created site will be given by the server to the user's browser in a compressed form, but CSS and JavaScript will not. Let's fix this:
### START CSS GZIP ###
# Requires mod_mime to be enabled.
# Send any files ending in .gz with x-gzip encoding in the header.
AddEncoding x-gzip .gz
# Gzip compressed css files are of the type 'text / css'.
ForceType text / css
RewriteEngine on
# Serve gzip compressed css files
RewriteCond% {HTTP: Accept-encoding} gzip
RewriteCond% {REQUEST_FILENAME} \. Gz -s
RewriteRule ^ (. *) \. Css $ 1 \ .css \ .gz [L, QSA, T = text / css]
### End CSS GZIP ###
If you need to use additional CSS and JavaScript in the theme templates, it is advisable to connect them using the commands:
in order for them to be optimized (included in one source CSS or JavaScript file) and compressed, together with all other CSS or JavaScript files used on the site.
Optimization of configuration and maintenance of Drupal
From optimization of Drupal using modules, we will move on to more complex optimization - optimization of configuration and maintenance of Drupal.
1. Reduce the storage time of user sessions. Since Drupal stores them in its database, reducing their storage time will offload the database, especially if thousands of users come to the site per day. By default, sessions are stored for 55 hours, reduce their storage time to 24 hours. To do this, on the server in the / sites / default folder in the settings.php file, change the line:
ini_set ('session.gc_maxlifetime', 200000);
to:
ini_set ('session.gc_maxlifetime', 86400); // 24 hours (in seconds)
Also in this file you can reduce the life of cached session pages to 24 hours by changing the line:
ini_set ('session.cache_expire', 200000);
to:
ini_set ('session.cache_expire', 1440); // 24 hours (in minutes)
Lastly in the same file, change the cookie storage time in the user's browser, reducing it to 24 hours:
ini_set ('session.cookie_lifetime', 86400); // 24 hours (in seconds)
If you set the cookie storage time in the user's browser to 0, then the cookie will be deleted immediately after the user closes the Internet browser.
2. Reduce the number of messages logging the site, stored in the database. On the page: Management -> Reports and Messages -> Reports in the database ( http://www.example.ru/admin/settings/logging/dblog ), set the required maximum of reports stored in the database. These reports are useful for viewing attempts to hack a site, so the minimum you can choose is 100 entries. You can view these reports by going to the page Management -> Recent entries in the system log ( http://www.example.ru/admin/reports/dblog ).
3. We will configure the execution of regular procedures (cron tasks), since when they are executed, the logs of message logs for logging the site, obsolete cache entries and other statistics are cleared. The easiest way to configure automatic start of regular procedures is to install the module - Poormanscron. Download this module at the Internet address - http://drupal.org/project/poormanscron . Unpack it into the / sites / all / modules folder, activate the module on the page: Management -> Modules ( http://www.example.ru/admin/build/modules ). Set the Cron launch interval on the page: Management -> Poormanscron ( http://www.example.ru/admin/settings/poormanscron ) to 360 minutes (once every 6 hours).
4. Drupal has a Throttle module that estimates the number of site visitors and disables some functionality if the threshold set by the administrator is reached. After activating the module on the page: Management -> Modules ( http://www.example.ru/admin/build/modules ), you can see that for some modules on this page, in addition to the inclusion flags, the flags appeared - should this module be regulated by Throttle or not. Also, some blocks can be regulated by Throttle (Management -> Blocks ( http://www.example.ru/admin/build/block )). Throttle settings are made on the page Management -> Regulator ( http://www.example.ru/admin/settings/throttle), which indicates the minimum number of anonymous visitors and the minimum number of registered users to include restrictions on the functionality of the site for them. On this page, we will also set the probabilistic limiter of the autoregulator to 20%, so that for one of every 5 requests for a page to be sent to the browser by the user, a query is made to the database to determine the load on the site.
Server optimization
Since the site server can run under different operating systems:
then in each case the server optimization settings will be different (i.e. the installation of eAccelerator on Windows and Lunux is very different). The following are only basic recommendations for optimizing the server. In detail, only the installation of the PHP accelerator on the Ubuntu 8.04 server is considered from the recommendations, since the PHP accelerator significantly speeds up the site.
1. Install eAccelerator, it is a PHP accelerator, the main purpose of which is to cache the binary representation of the code.
Connect to the server via SSH and log in as root. Run the commands to install the additional php5-dev package:
sudo apt-get install php5-dev
sudo apt-get install make
run the commands to install eAccelerator:
sudo cd / tmp /
sudo wgetbart.eaccelerator.net/source/0.9.5.3/eaccelerator-0.9.5.3.tar.bz2
sudo tar xvjf eaccelerator-0.9.5.3.tar.bz2
sudo cd eaccelerator-0.9.5.3
sudo phpize
sudo ./configure --enable- = the shared eaccelerator
sudo the make
sudo the make the install
Edit the php.ini file in the folder / etc / php5 / apache2, insert at the beginning of the file after the tag [PHP] code:
; eAccelerator configuration
; Note that eAccelerator may also be installed as a PHP extension or as a zend_extension
; If you are using a thread safe build of PHP you must use
; zend_extension_ts instead of zend_extension
; extension = "/usr/lib/php5/20060613+lfs/eaccelerator.so"
zend_extension = "/usr/lib/php5/20060613+lfs/eaccelerator.so"
eaccelerator.shm_size = "16"
eaccelerator.cache_dir = "/ var / cache / eaccelerator"
eaccelerator.enable = "1"
eaccelerator.optimizer = "1 "
eaccelerator.check_mtime =" 1 "
eaccelerator.debug =" 0 "
eaccelerator.filter =" "
eaccelerator.shm_max =" 0 "
eaccelerator.shm_ttl =" 0 "
eaccelerator.shm_prune_period =" 0 "
eaccelerator.shm_only =" 0 "
eaccelerator.compress = "1"
eaccelerator.compress_level = "9"
eaccelerator.allowed_admin_path = "/ var / www / eaccelerator"
When using Zend Optimizer and / or ionCube Loader, the above code will look like:
; eAccelerator configuration
; Note that eAccelerator may also be installed as a PHP extension or as a zend_extension
; If you are using a thread safe build of PHP you must use
; zend_extension_ts instead of zend_extension
; extension = "/usr/lib/php5/20060613+lfs/eaccelerator.so"
zend_extension = "/usr/lib/php5/20060613+lfs/eaccelerator.so"
eaccelerator.shm_size = "16"
eaccelerator. cache_dir = "/ var / cache / eaccelerator"
eaccelerator.enable = "1"
eaccelerator.optimizer = "1"
eaccelerator.check_mtime = "1"
eaccelerator.debug = "0"
eaccelerator.filter = ""
eaccelerator.shm_max = "0"
eaccelerator.shm_ttl = "0"
eaccelerator. shm_prune_period = "0"
eaccelerator.shm_only = "0"
eaccelerator.compress = "1"
eaccelerator.compress_level = "9"
eaccelerator.allowed_admin_path = "/ var / www / eaccelerator"
; ionCube Loader configuration
zend_extension = / usr / local / lib / ioncube / ioncube_loader_lin_5.2.so
;
= the zend_extension / usr / local / lib / the Zend / ZendOptimizer.so
zend_optimizer.optimization_level = 15
Create a cache directory for eAccelerator execute the command:
sudo the mkdir -p / var / cache / eaccelerator
sudo the chmod 0777 / var / cache / eaccelerator
Restart the the Apache:
sudo /etc/init.d/apache2 restart
2. We recommend that you install the nginx Web server and configure it to work with the Apache Web server so that the pages give the Apache user’s browser and static content (CSS, JavaScript, photos, etc.) nginx Or completely replace the Apache web server with the nginx web server.
3. Install the mod_expires module in Apache, which allows Drupal to send Expires HTTP headers, caching all static files (images, css, javascript, etc.) in the user's Internet browser for a certain period or until new versions of files appear. The interaction settings between Drupal and the mod_expires module of the Apache Web server are located in the .htaccess file in the root directory of the site:
# Enable mod_expires.
# Allow expiration.
ExpiresActive On
# Cache all files two weeks after access (A).
ExpiresDefault A1209600
# Do not cache dynamically generated pages.
ExpiresByType text / html A1
4. To speed up the processing of .htaccess files by the web server, their contents can be transferred to the main Apache configuration file - httpd.conf. After that, you must prohibit the search for .htaccess files within the root directory of the web server by setting AllowOverride to None:
AllowOverride
...
Since some modules inside their directories may contain .htaccess files, you should carefully work with this type of optimization so that when transferring the contents of all .htaccess files to httpd.conf, do not miss more than one .htaccess file.
5. Install on the server:
6. Turn on the MySQL cache and set its size to 64 megabytes. To do this, edit the my.cnf file in the / etc / mysql folder (when using Ubuntu 8.04). Change the value:
# query_cache_limit = 1M
# query_cache_size = 16M
to:
query_cache_limit = 1M
query_cache_size = 64M
Then restart the MySQL command:
/etc/init.d/mysql restart
Too small cache size is inefficient, and too large cache size leads to that the search for the necessary information in the cache takes a long time. Therefore, we recommend that you experiment with the size of the cache on each specific server and select its optimal size.
7. Check - CPU load, lack of RAM or disk space and possible overload of the server’s communication line with the Internet. If we need to place the Database on a separate server, for this we will change, the settings for connecting to the database are located in the settings.php file (in the / sites / default folder). Or we will place the site on a cluster of servers (for example: using the services of the Amazon C2 service).
Conclusion
To view server information from Drupal there is a convenient module - System information ( http://drupal.org/project/systeminfo ). After installing and activating information about your server, see the page - http://www.example.ru/admin/reports/systeminfo .
To test the speed of the site and optimize its content, it is very convenient to use the YSlow plugin for the Firefox Internet browser, which shows detailed statistics on loading pages from your site.
An updated version of the article is divided into chapters, available on the website: http://www.mydrupalbook.ru/ .
Author: Tsaplina Elena & Vyacheslav
Drupal is a fairly common CMS and this left its mark on it - the basic Drupal delivery is not a ready-made solution for a certain type of site, but the foundation for its creation. There are “assemblies” based on Drupal specialized for certain types of sites, for example: news sites. But such assemblies are currently not widely distributed and poorly supported. In this regard, when creating an Internet site based on the standard Drupal delivery, a large number of ready-made additional modules and themes for Drupal are used, or new modules and themes are developed specifically for the created Internet site. The last step in creating a site is its optimization, which can be conditionally divided into 4 steps:
- Drupal built-in optimization;
- Drupal optimization using modules;
- Drupal configuration and maintenance optimization;
- server optimization.
Built-in Drupal Optimization
1. Disable all unused modules. Since when generating a page before sending it to the user's browser, the code of certain modules can be executed even if the functionality of this module is not used on the site. The processor time of the server will be spent on code execution, which will lead to longer page generation. An example of such a module is Statistics. Instead of statistics generated by this module, you can use the statistics of the service - Google Analytics.
2. When creating the site, we use Drupal version 6, as it better implements internal caching tools. Also, additional modules (Views, Panel, etc.) for Drupal version 6 have implemented effective caching methods. Unfortunately, not all Drupal version 5 modules are implemented for Drupal version 6 (for example, the Sphinx module), we will not forget about this when planning the development of an Internet site. Next, we will consider only Drupal version 6.
3. We’ll carefully consider the options for using modules similar to the CCK (Content Construction Kit), before implementing the plan for creating the site. For example, the simple task of storing thousands of types of products, their names and descriptions in the database of a site is solved with the help of:
- creating thousands of taxonomy terms and linking them to a particular type of material,
- adding to a certain material an additional CCK field in which the type of products will be stored.
When complicating the task using the condition that all types of products should be divided into 10 groups, the problem is solved in two ways. Option one, using a taxonomy:
- Taxonomy allows you to create a hierarchy of terms in a dictionary, i.e. in a dictionary with terms there may be 10 terms of the first level, and the remaining terms will be descendants of one of these 10 terms. Create the desired hierarchy of terms in the dictionary.
- Install an additional module - Hierarchical Select (http://drupal.org/project/hierarchical_select), which allows depending on the nesting levels of the taxonomy dictionary to display a certain number of dropping out squeaks. Those. when adding a new article about a product to the user, the user will be presented with a single drop-down list in which one of 10 top-level terms (product type groups) can be selected. After making a selection, the user will be presented with another drop-down list in which the descendants of the given term will be displayed in the hierarchical tree of terms of the given taxonomy dictionary (product types).
Option two using CCK:
- It is necessary for a certain material to add 2 additional CCK fields, one for storing product groups and one for storing product types.
- It is necessary to configure the interaction of these fields depending on the choice of values in them.
The main error in solving such problems creates an additional load on the database:
- creation of 10 CCK fields for a particular material, one field for each group;
- when creating a CCK field for a particular material, its length is not specified (therefore, by default it is considered that it is the maximum possible).
4. We use the built-in caching of Drupal. It allows you to cache information retrieved from the database, as well as information obtained by processing the extracted information from PHP.
Caching of the menu system, filters of input formats, administration variables (for example: site name) and module settings is done automatically. Other caching parameters can be configured on the page: Management -> Performance ( http://www.example.ru/admin/settings/performance ).
On this page you can configure:
- page compression;
- block caching;
- CSS file optimization;
- JavaScript file optimization.
Turn on page caching in normal mode. In this mode of page caching, when viewing a page for the first time (by an anonymous, unregistered user in the system), the generated page is saved to the cache. Later, when viewing this page (by an anonymous user), it is not generated again, but is taken from the cache, which greatly speeds up Drupal.
When you enable page caching in the aggressive mode, when generating a page, the loading and unloading of enabled modules is skipped, so some of the modules may work incorrectly or not work at all.
Set the minimum page cache lifetime for anonymous users. This parameter determines how long after caching the page, it checks whether the contents of this page are updated or not. If updated, then the cache of this page is cleared. Those. if the site administrator has changed the content of the page, he will see it immediately, and anonymous users, only after a minimum cache lifetime.
We enable page compression to save the compressed page cache and to transfer the page to the user's browser in a compressed form, if it supports gzip compression. Compression is performed using the zlib library installed as an extension in PHP.
Turn on block caching. The principle of block caching is similar to the principle of page caching. For a super user (the first registered user when installing Drupal, his id is 1), the blocks are never cached.
Turn on CSS and JavaScript file optimization. This will reduce their size and the number of calls to the server when loading pages into the browser. All CSS and JavaScript files are assembled into one (your own file for CSS and your own for JavaScript). Which reduces the number of calls to the server when loading the page.
Optimizing Drupal with Modules
1. Install the Authenticated User Page Caching (Authcache) module, you can download it at the Internet address - http://drupal.org/project/authcache. This module allows you to cache pages for both anonymous users and authenticated (“logged in”) users better than the built-in Drupal caching. When installing this module, you must reconfigure the dynamic content on the pages (for example: displaying the name of an authenticated user).
Authcache maintains a compressed page cache separately for each user or role. The cache is stored in the database or in a third-party caching tool (memcahed, APC, etc.). Cached versions of pages for authenticated users (except for the super-user) are transferred using AJAX, so a very fast page display in the browser is achieved. If the authenticated user has JavaScript disabled in the browser, then he does not receive pages from the cache. On some servers, page loading speed decreases to 1 millisecond.
To install the module:
- download it;
- unpack the module into the / sites / all / modules folder;
- copy the ajax_authcache.php file from the module folder to the root directory of the site (the index.php file is also located there);
- open the settings.php file (in the / sites / default folder) and add the following code (without notes for // ...) to the beginning of the file after the tag
$ conf ['cache_inc'] = './sites/all/modules/authcache/api/authcache.inc';
$ conf ['authcache'] = array (
'default' => array (
// caching technology - apc, memcache, db, file, eacc or xcache
'engine' => 'db',
// if we use memcached (host: port, e..g, 'localhost: 11211')
'server' => array (),
// if we use memcached shared single process
'shared' => TRUE,
// prefix key cache (for several sites)
'prefix' => '',
// if we use caching on files - specify the path
// to save them
'path'
// static array cache (advanced) // static cache array (extended)
'static' => FALSE,
),
);
In this code, the settings of the Authcache module are set. We indicate that we will store the page cache in the database ('engine' => 'db'), so all other settings do not matter, we leave them unchanged. You can read more about the parameters of this code on the page - http://drupal.org/project/cacherouter (in English).
We enable the Authcache module on the page: Management -> Modules ( http://www.example.ru/admin/build/modules ). After that, we will configure its work on the page: Management -> Performance -> Authcache (http://www.example.ru/admin/settings/performance/authcache ):
- specify the roles for which you want to cache content;
- cancel all user sessions (checkbox - Invalidate all user sessions) at the first start;
- setting the cache storage time (in hours);
- press the save and clear cached pages button to save the changes.
We’ll change the settings of the elements on the site’s pages, so that the page for different users belonging to the same role would look the same (i.e., for example: we will forbid users to control the visibility of blocks on the site, if such blocks exist).
We use variables in the themes templates:
- $ user_name - to display the name of the authenticated user;
- $ user_link - to display links associated with the user profile;
- $ is_page_authcache - if set to TRUE, then all the hooks for this skin template will be cached.
You can also familiarize yourself with the example - / sites / all / modules / authcache / modules / authcache_example, which shows how to configure blocks with user content (with user content).
2. If you need to cache pages only for anonymous users (without authenticated users), you can install the Cache Router module. This module is the basis of the Authcache module and caches pages better than Drupal's built-in caching. Download the module at the Internet address - http://drupal.org/project/authcache . After downloading, unpack the module into the / sites / all / modules folder. We enable the Cache Router module on the page: Management -> Modules ( http://www.example.ru/admin/build/modules ). Open the settings.php file (in the / sites / default folder) and add the following code to the beginning of the file before the tag
$ conf ['cache_inc'] = './sites/all/modules/cacherouter/cacherouter.inc';
$ conf ['cacherouter'] = array (
'default' => array (
'engine' => 'db',
'server' => array (),
'shared' => TRUE,
'prefix' => '',
'path' => 'sites / default / files / filecache',
'static' => FALSE,
'fast_cache' => TRUE,
),
);
3. After the implementation of the above actions, the pages of the created site will be given by the server to the user's browser in a compressed form, but CSS and JavaScript will not. Let's fix this:
- download the CSS Gzip module from the page - http://drupal.org/project/css_gzip ;
- download the JavaScript Aggregator module from the page - http://drupal.org/project/javascript_aggregator ;
- unpack the modules in the / sites / all / modules folder;
- enable the modules on the page: Management -> Modules ( http://www.example.ru/admin/build/modules );
- activate CSS and JavaScript compression on the page: Management -> Performance ( http://www.example.ru/admin/settings/performance ), checking the checkboxes - GZip CSS and GZip JavaScript;
- make a change to the .htaccess file located in the root directory of the site (based on the data from README.txt which is part of the Gzip CSS module), we will write honey with tags
and following code:
### START CSS GZIP ###
# Requires mod_mime to be enabled.
# Send any files ending in .gz with x-gzip encoding in the header.
AddEncoding x-gzip .gz
# Gzip compressed css files are of the type 'text / css'.
ForceType text / css
RewriteEngine on
# Serve gzip compressed css files
RewriteCond% {HTTP: Accept-encoding} gzip
RewriteCond% {REQUEST_FILENAME} \. Gz -s
RewriteRule ^ (. *) \. Css $ 1 \ .css \ .gz [L, QSA, T = text / css]
### End CSS GZIP ###
- save the settings and clear the cache.
If you need to use additional CSS and JavaScript in the theme templates, it is advisable to connect them using the commands:
- drupal_add_css ('CSS path relative to the root directory of the site');
- drupal_add_js ('path to JavaScript relative to the root directory of the site');
in order for them to be optimized (included in one source CSS or JavaScript file) and compressed, together with all other CSS or JavaScript files used on the site.
Optimization of configuration and maintenance of Drupal
From optimization of Drupal using modules, we will move on to more complex optimization - optimization of configuration and maintenance of Drupal.
1. Reduce the storage time of user sessions. Since Drupal stores them in its database, reducing their storage time will offload the database, especially if thousands of users come to the site per day. By default, sessions are stored for 55 hours, reduce their storage time to 24 hours. To do this, on the server in the / sites / default folder in the settings.php file, change the line:
ini_set ('session.gc_maxlifetime', 200000);
to:
ini_set ('session.gc_maxlifetime', 86400); // 24 hours (in seconds)
Also in this file you can reduce the life of cached session pages to 24 hours by changing the line:
ini_set ('session.cache_expire', 200000);
to:
ini_set ('session.cache_expire', 1440); // 24 hours (in minutes)
Lastly in the same file, change the cookie storage time in the user's browser, reducing it to 24 hours:
ini_set ('session.cookie_lifetime', 86400); // 24 hours (in seconds)
If you set the cookie storage time in the user's browser to 0, then the cookie will be deleted immediately after the user closes the Internet browser.
2. Reduce the number of messages logging the site, stored in the database. On the page: Management -> Reports and Messages -> Reports in the database ( http://www.example.ru/admin/settings/logging/dblog ), set the required maximum of reports stored in the database. These reports are useful for viewing attempts to hack a site, so the minimum you can choose is 100 entries. You can view these reports by going to the page Management -> Recent entries in the system log ( http://www.example.ru/admin/reports/dblog ).
3. We will configure the execution of regular procedures (cron tasks), since when they are executed, the logs of message logs for logging the site, obsolete cache entries and other statistics are cleared. The easiest way to configure automatic start of regular procedures is to install the module - Poormanscron. Download this module at the Internet address - http://drupal.org/project/poormanscron . Unpack it into the / sites / all / modules folder, activate the module on the page: Management -> Modules ( http://www.example.ru/admin/build/modules ). Set the Cron launch interval on the page: Management -> Poormanscron ( http://www.example.ru/admin/settings/poormanscron ) to 360 minutes (once every 6 hours).
4. Drupal has a Throttle module that estimates the number of site visitors and disables some functionality if the threshold set by the administrator is reached. After activating the module on the page: Management -> Modules ( http://www.example.ru/admin/build/modules ), you can see that for some modules on this page, in addition to the inclusion flags, the flags appeared - should this module be regulated by Throttle or not. Also, some blocks can be regulated by Throttle (Management -> Blocks ( http://www.example.ru/admin/build/block )). Throttle settings are made on the page Management -> Regulator ( http://www.example.ru/admin/settings/throttle), which indicates the minimum number of anonymous visitors and the minimum number of registered users to include restrictions on the functionality of the site for them. On this page, we will also set the probabilistic limiter of the autoregulator to 20%, so that for one of every 5 requests for a page to be sent to the browser by the user, a query is made to the database to determine the load on the site.
Server optimization
Since the site server can run under different operating systems:
- Windows
- Lunux
- FreeBSD
then in each case the server optimization settings will be different (i.e. the installation of eAccelerator on Windows and Lunux is very different). The following are only basic recommendations for optimizing the server. In detail, only the installation of the PHP accelerator on the Ubuntu 8.04 server is considered from the recommendations, since the PHP accelerator significantly speeds up the site.
1. Install eAccelerator, it is a PHP accelerator, the main purpose of which is to cache the binary representation of the code.
Connect to the server via SSH and log in as root. Run the commands to install the additional php5-dev package:
sudo apt-get install php5-dev
sudo apt-get install make
run the commands to install eAccelerator:
sudo cd / tmp /
sudo wgetbart.eaccelerator.net/source/0.9.5.3/eaccelerator-0.9.5.3.tar.bz2
sudo tar xvjf eaccelerator-0.9.5.3.tar.bz2
sudo cd eaccelerator-0.9.5.3
sudo phpize
sudo ./configure --enable- = the shared eaccelerator
sudo the make
sudo the make the install
Edit the php.ini file in the folder / etc / php5 / apache2, insert at the beginning of the file after the tag [PHP] code:
; eAccelerator configuration
; Note that eAccelerator may also be installed as a PHP extension or as a zend_extension
; If you are using a thread safe build of PHP you must use
; zend_extension_ts instead of zend_extension
; extension = "/usr/lib/php5/20060613+lfs/eaccelerator.so"
zend_extension = "/usr/lib/php5/20060613+lfs/eaccelerator.so"
eaccelerator.shm_size = "16"
eaccelerator.cache_dir = "/ var / cache / eaccelerator"
eaccelerator.enable = "1"
eaccelerator.optimizer = "1 "
eaccelerator.check_mtime =" 1 "
eaccelerator.debug =" 0 "
eaccelerator.filter =" "
eaccelerator.shm_max =" 0 "
eaccelerator.shm_ttl =" 0 "
eaccelerator.shm_prune_period =" 0 "
eaccelerator.shm_only =" 0 "
eaccelerator.compress = "1"
eaccelerator.compress_level = "9"
eaccelerator.allowed_admin_path = "/ var / www / eaccelerator"
When using Zend Optimizer and / or ionCube Loader, the above code will look like:
; eAccelerator configuration
; Note that eAccelerator may also be installed as a PHP extension or as a zend_extension
; If you are using a thread safe build of PHP you must use
; zend_extension_ts instead of zend_extension
; extension = "/usr/lib/php5/20060613+lfs/eaccelerator.so"
zend_extension = "/usr/lib/php5/20060613+lfs/eaccelerator.so"
eaccelerator.shm_size = "16"
eaccelerator. cache_dir = "/ var / cache / eaccelerator"
eaccelerator.enable = "1"
eaccelerator.optimizer = "1"
eaccelerator.check_mtime = "1"
eaccelerator.debug = "0"
eaccelerator.filter = ""
eaccelerator.shm_max = "0"
eaccelerator.shm_ttl = "0"
eaccelerator. shm_prune_period = "0"
eaccelerator.shm_only = "0"
eaccelerator.compress = "1"
eaccelerator.compress_level = "9"
eaccelerator.allowed_admin_path = "/ var / www / eaccelerator"
; ionCube Loader configuration
zend_extension = / usr / local / lib / ioncube / ioncube_loader_lin_5.2.so
;
= the zend_extension / usr / local / lib / the Zend / ZendOptimizer.so
zend_optimizer.optimization_level = 15
Create a cache directory for eAccelerator execute the command:
sudo the mkdir -p / var / cache / eaccelerator
sudo the chmod 0777 / var / cache / eaccelerator
Restart the the Apache:
sudo /etc/init.d/apache2 restart
2. We recommend that you install the nginx Web server and configure it to work with the Apache Web server so that the pages give the Apache user’s browser and static content (CSS, JavaScript, photos, etc.) nginx Or completely replace the Apache web server with the nginx web server.
3. Install the mod_expires module in Apache, which allows Drupal to send Expires HTTP headers, caching all static files (images, css, javascript, etc.) in the user's Internet browser for a certain period or until new versions of files appear. The interaction settings between Drupal and the mod_expires module of the Apache Web server are located in the .htaccess file in the root directory of the site:
# Enable mod_expires.
# Allow expiration.
ExpiresActive On
# Cache all files two weeks after access (A).
ExpiresDefault A1209600
# Do not cache dynamically generated pages.
ExpiresByType text / html A1
4. To speed up the processing of .htaccess files by the web server, their contents can be transferred to the main Apache configuration file - httpd.conf. After that, you must prohibit the search for .htaccess files within the root directory of the web server by setting AllowOverride to None:
AllowOverride
...
Since some modules inside their directories may contain .htaccess files, you should carefully work with this type of optimization so that when transferring the contents of all .htaccess files to httpd.conf, do not miss more than one .htaccess file.
5. Install on the server:
- a system for analyzing log files (for example: AWstats),
- server performance monitoring system (for example: Munin);
- system for accounting network traffic (for example: Vnstat).
6. Turn on the MySQL cache and set its size to 64 megabytes. To do this, edit the my.cnf file in the / etc / mysql folder (when using Ubuntu 8.04). Change the value:
# query_cache_limit = 1M
# query_cache_size = 16M
to:
query_cache_limit = 1M
query_cache_size = 64M
Then restart the MySQL command:
/etc/init.d/mysql restart
Too small cache size is inefficient, and too large cache size leads to that the search for the necessary information in the cache takes a long time. Therefore, we recommend that you experiment with the size of the cache on each specific server and select its optimal size.
7. Check - CPU load, lack of RAM or disk space and possible overload of the server’s communication line with the Internet. If we need to place the Database on a separate server, for this we will change, the settings for connecting to the database are located in the settings.php file (in the / sites / default folder). Or we will place the site on a cluster of servers (for example: using the services of the Amazon C2 service).
Conclusion
To view server information from Drupal there is a convenient module - System information ( http://drupal.org/project/systeminfo ). After installing and activating information about your server, see the page - http://www.example.ru/admin/reports/systeminfo .
To test the speed of the site and optimize its content, it is very convenient to use the YSlow plugin for the Firefox Internet browser, which shows detailed statistics on loading pages from your site.
An updated version of the article is divided into chapters, available on the website: http://www.mydrupalbook.ru/ .
Author: Tsaplina Elena & Vyacheslav