Drupal optimization
Introduction
Drupal is a content widespread CMS and this has put its mark on it - the basic delivery of Drupal is not a ready-made solution for a certain type of site, but a 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 very common and are 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 being developed specifically for the Internet site being created. The last stage of work on the site is its optimization, which can be divided into 4 steps:
Native 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 a longer page generation. An example of such a module is Statistics. Instead of statistics provided by this module, you can use the statistics of the service - Google Analytics.
2. When creating a site, we use Drupal version 6, since it has better implemented internal caching tools. Also in the additional modules (Views, Panel, etc.) for Drupal version 6, effective caching methods are implemented. Unfortunately, not all Drupal version 5 modules are implemented for Drupal version 6 (for example, the Sphinx module), let's not forget about it when planning the development of an Internet site. Further we will consider only Drupal version 6.
')
3. Let's think about ways to use modules like CCK (Content Construction Kit) before implementing the plan when creating the site. For example, a simple task of storing thousands of types of products in the site database, their names and descriptions, is solved with the help of:
With the complication of the problem using the condition that all types of products should be divided into 10 groups, the problem is solved in two ways. Option one, using taxonomy:
Option two, using CCK:
The main error in solving such problems creates an additional load on the database:
4. We use built-in Drupal caching. 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, input format filters, administration variables (for example: site name) and module settings is done automatically. The remaining caching options 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 the page for the first time (by an anonymous, unregistered user in the system), the generated page is saved in the cache. Later, when viewing this page (by an anonymous user), it is not re-generated, but taken from the cache, which significantly speeds up the work of Drupal.
When page caching is turned on in the aggressive mode, when the page is generated, the loading and unloading of the included modules is skipped, so some modules may not work correctly or not at all.
Configure the minimum page cache lifetime for anonymous users. This parameter determines how long after the page is cached, whether the content of this page is updated or not. If updated, the cache of this page is cleared. Those. if the site administrator has changed the page content, he will see it immediately, and anonymous users, only after the minimum cache lifetime.
Enable page compression to save 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.
Enable caching of blocks. The principle of block caching is similar to the page caching principle. For a super user (the first registered user when installing Drupal, his id is 1) the blocks are never cached.
Enable optimization of CSS and JavaScript files. This will reduce their size and the number of accesses to the server when pages are loaded into the browser. All CSS and JavaScript files are collected in one (your file for CSS and your own for JavaScript). That reduces the number of calls to the server when the page loads.
Optimize 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 more qualitatively than Drupal's inline caching. When installing this module, you need to reconfigure the dynamic content on the pages (for example: display the name of the authenticated user).
Authcache saves a compressed page cache for each user or role separately. The cache is stored in a database or in a third-party caching facility (memcahed, APC, etc.). Cached versions of pages for authenticated users (except for the super user) are transmitted using AJAX, so a very fast page display in the browser is achieved. If the authenticated user has javascript disabled in the browser, he gets non-cache pages. On some servers, the page loading speed is reduced 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 multiple sites)
'prefix' => '',
// if we use caching on files - specify their path
// save
'path' => 'files / filecache',
// static array cache (advanced) // static cache array (advanced)
'static' => FALSE,
),
);
In this code, the Authcache module settings are set. We specify that we will store the page cache in the database ('engine' => 'db'), so all other settings do not matter, leave them unchanged. More information about the parameters of this code can be found on the page - http://drupal.org/project/cacherouter (in English).
Enable the Authcache module on the page: Management -> Modules ( http://www.example.ru/admin/build/modules ). After that, we configure its operation on the page: Management -> Performance -> Authcache ( http://www.example.ru/admin/settings/performance/authcache ):
Change the settings of the elements on the pages of the site, so that the page for different users belonging to the same role would look the same (ie, for example: we will forbid users to control the visibility of blocks on the site, if such blocks exist).
We use variables in theme templates:
You can also get acquainted with an example - / sites / all / modules / authcache / modules / authcache_example, which shows how to configure blocks with custom 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 underlies the Authcache module and caches pages better than the built-in Drupal caching. Download the module at the Internet address - http://drupal.org/project/authcache . After downloading, unpack the module in the / sites / all / modules folder. 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 <? Php 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 actions above, 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 are not. Fix this:
### START CSS GZIP ###
# Requires mod_mime to be enabled.
<IfModule mod_mime.c>
# Send any files ending in .gz with x-gzip encoding in the header.
AddEncoding x-gzip .gz
</ IfModule>
# Gzip compressed css files of the type 'text / css'.
<FilesMatch "\ .css \ .gz $">
ForceType text / css
</ FilesMatch>
<IfModule mod_rewrite.c>
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]
</ IfModule>
### End CSS GZIP ###
If you need to use additional CSS and JavaScript in the skin templates, it is advisable to connect them using the commands:
in order to be optimized (included in one source CSS or JavaScript file) and compressed, along with all other CSS or JavaScript files used on the site.
Optimize Drupal configuration and maintenance
From optimizing Drupal using modules, let's move on to more complex optimization — optimizing the 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 unload the database, especially if thousands of users come to the site per day. By default, sessions are stored for 55 hours, reducing 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);
on:
ini_set ('session.gc_maxlifetime', 86400); // 24 hours (in seconds)
Also in this file, you can shorten the lifetime of cached session pages to 24 hours by changing the line:
ini_set ('session.cache_expire', 200000);
on:
ini_set ('session.cache_expire', 1440); // 24 hours (in minutes)
Lastly, in the same file, we 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 storage time for cookies in the user's browser to 0, then the cookie will be deleted immediately after the Internet browser is closed by the user.
2. Reduce the number of messages logging the work site, stored in the database. On the page: Manage -> Reports and Messages -> Database Reports ( http://www.example.ru/admin/settings/logging/dblog ), set the required maximum of reports stored in the database. These reports are useful for viewing site hacking attempts, so the minimum that you can select is 100 entries. You can view these reports by going to the Manage -> Recent entries in the system log ( http://www.example.ru/admin/reports/dblog ).
3. Configure the execution of regular procedures (cron tasks), since when they are executed, the logs of the site logging messages, outdated cache entries, and other statistical data are cleared. The easiest way to configure automatic startup of regular procedures is to install the module - Poormanscron. Download this module at the Internet address - http://drupal.org/project/poormanscron . We will 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, which estimates the number of visitors to the site 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 some of the modules on this page have checkboxes next to the enable checkboxes - whether this module should be controlled by Throttle or not. Also, some blocks can be regulated by Throttle (Control -> Blocks ( http://www.example.ru/admin/build/block )). Throttle settings are made on the Manage -> Regulator page ( http://www.example.ru/admin/settings/throttle ), where you specify the minimum number of anonymous visitors and the minimum number of registered users to enable site restriction for them. On this page, we also set the probabilistic limiter of the autoregulator to 20%, so that for one out of every 5 requests for issuing a page to the browser to the user, a query is made to the database to determine the load on the site.
Server optimization
Since the site server can work under different operating systems:
then in each case the server optimization settings will be different (i.e., the installation of eAccelerator in Windows and Lunux is very different). Below are only the basic recommendations for server optimization. Details of the recommendations considered only the installation of a PHP accelerator on the Ubuntu 8.04 server, since the PHP accelerator significantly speeds up the work of 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 wget bart.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-eaccelerator = shared
sudo make
sudo make install
Let's edit the php.ini file in the / etc / php5 / apache2 folder, insert the code in the beginning of the file after the [PHP] tag:
; eAccelerator configuration
; Note that it can be installed as a PHP extension or as a zend_extension
; If you are using php you need 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 code above will look like this:
; eAccelerator configuration
; Note that it can be installed as a PHP extension or as a zend_extension
; If you are using php you need 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
; Zend Optimizer configuration
zend_extension = / usr / local / lib / Zend / ZendOptimizer.so
zend_optimizer.optimization_level = 15
Create a cache directory for eAccelerator by running the following commands:
sudo mkdir -p / var / cache / eaccelerator
sudo chmod 0777 / var / cache / eaccelerator
Restart 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 are sent to the browser by the Apache user, and the static content (CSS, JavaScript, photos, etc.) is 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 by 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 settings for interaction 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.
<IfModule mod_expires.c>
# Allow expiration.
ExpiresActive On
# Cache all files for two weeks after access (A).
ExpiresDefault A1209600
# Do not cache dynamically generated pages.
ExpiresByType text / html A1
</ IfModule>
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, it is necessary to prohibit the search for .htaccess files within the root directory of the web server by setting AllowOverride to None:
<Directory />
AllowOverride
...
</ Directory>
Since some modules inside their directories may contain .htaccess files, you should carefully work with this type of optimization, so that if you transfer 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
on:
query_cache_limit = 1M
query_cache_size = 64M
Then restart MySQL with the command:
/etc/init.d/mysql restart
A cache that is too small is inefficient, and a cache that is too large causes the search for the necessary information in the cache to take a long time. Therefore, we recommend experimenting with the cache size on each specific server and selecting its optimal size.
7. Check - the CPU load, the lack of RAM or disk space and possible overload of the server communication line with the Internet. If it is necessary to place the Database on a separate server, for this we change, the settings for connecting to the database are 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 Amazon C2).
Conclusion
To view server information from Drupal there is a handy module - System information ( http://drupal.org/project/systeminfo ). After it is installed and activated, information about your server can be viewed on 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 Internet browser Firefox, which shows detailed statistics on how to load pages from your site.
An updated version of the article is divided into chapters, available on the website: http://www.mydrupalbook.ru/ .
Author: Elena Tsaplina & Vyacheslav
Drupal is a content widespread CMS and this has put its mark on it - the basic delivery of Drupal is not a ready-made solution for a certain type of site, but a 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 very common and are 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 being developed specifically for the Internet site being created. The last stage of work on the site is its optimization, which can be divided into 4 steps:
- built-in Drupal optimization;
- optimization of Drupal using modules;
- optimization of the configuration and maintenance of Drupal;
- server optimization.
Native 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 a longer page generation. An example of such a module is Statistics. Instead of statistics provided by this module, you can use the statistics of the service - Google Analytics.
2. When creating a site, we use Drupal version 6, since it has better implemented internal caching tools. Also in the additional modules (Views, Panel, etc.) for Drupal version 6, effective caching methods are implemented. Unfortunately, not all Drupal version 5 modules are implemented for Drupal version 6 (for example, the Sphinx module), let's not forget about it when planning the development of an Internet site. Further we will consider only Drupal version 6.
')
3. Let's think about ways to use modules like CCK (Content Construction Kit) before implementing the plan when creating the site. For example, a simple task of storing thousands of types of products in the site database, their names and descriptions, is solved with the help of:
- creating thousands of taxonomy terms and linking them to a specific type of material,
- add a specific CCK field material to a specific material in which the product type will be stored.
With the complication of the problem using the condition that all types of products should be divided into 10 groups, the problem is solved in two ways. Option one, using taxonomy:
- Taxonomy allows you to create a hierarchy of terms in the dictionary, i.e. There are 10 first-level terms in the glossary 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 drop-downs from squeaks. Those. When a new product article is added to the site, a user will be shown one drop-down list in which you can select one of 10 first-level terms (group of product types). After making a selection, the user will be shown another drop-down list in which the descendants of this term will be displayed in the hierarchical terminology tree 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, the second for storing product types.
- It is necessary to adjust 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 a specific material 10 CCK fields, field for each group;
- when creating a CCK field for a certain material, its length is not indicated (therefore, by default it is considered that it is the maximum possible).
4. We use built-in Drupal caching. 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, input format filters, administration variables (for example: site name) and module settings is done automatically. The remaining caching options 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 the page for the first time (by an anonymous, unregistered user in the system), the generated page is saved in the cache. Later, when viewing this page (by an anonymous user), it is not re-generated, but taken from the cache, which significantly speeds up the work of Drupal.
When page caching is turned on in the aggressive mode, when the page is generated, the loading and unloading of the included modules is skipped, so some modules may not work correctly or not at all.
Configure the minimum page cache lifetime for anonymous users. This parameter determines how long after the page is cached, whether the content of this page is updated or not. If updated, the cache of this page is cleared. Those. if the site administrator has changed the page content, he will see it immediately, and anonymous users, only after the minimum cache lifetime.
Enable page compression to save 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.
Enable caching of blocks. The principle of block caching is similar to the page caching principle. For a super user (the first registered user when installing Drupal, his id is 1) the blocks are never cached.
Enable optimization of CSS and JavaScript files. This will reduce their size and the number of accesses to the server when pages are loaded into the browser. All CSS and JavaScript files are collected in one (your file for CSS and your own for JavaScript). That reduces the number of calls to the server when the page loads.
Optimize 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 more qualitatively than Drupal's inline caching. When installing this module, you need to reconfigure the dynamic content on the pages (for example: display the name of the authenticated user).
Authcache saves a compressed page cache for each user or role separately. The cache is stored in a database or in a third-party caching facility (memcahed, APC, etc.). Cached versions of pages for authenticated users (except for the super user) are transmitted using AJAX, so a very fast page display in the browser is achieved. If the authenticated user has javascript disabled in the browser, he gets non-cache pages. On some servers, the page loading speed is reduced to 1 millisecond.
To install the module:
- download it;
- unpack the module in 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 (no notes for // ...) to the beginning of the file after the <? php 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 multiple sites)
'prefix' => '',
// if we use caching on files - specify their path
// save
'path' => 'files / filecache',
// static array cache (advanced) // static cache array (advanced)
'static' => FALSE,
),
);
In this code, the Authcache module settings are set. We specify that we will store the page cache in the database ('engine' => 'db'), so all other settings do not matter, leave them unchanged. More information about the parameters of this code can be found on the page - http://drupal.org/project/cacherouter (in English).
Enable the Authcache module on the page: Management -> Modules ( http://www.example.ru/admin/build/modules ). After that, we configure its operation on the page: Management -> Performance -> Authcache ( http://www.example.ru/admin/settings/performance/authcache ):
- specify the roles for which you want to cache the content;
- cancel all user sessions (checkbox - Invalidate all user sessions) at the first start;
- setting the cache storage time (in hours);
- press the button to save and clear the cache (Save & clear cached pages) to save the changes.
Change the settings of the elements on the pages of the site, so that the page for different users belonging to the same role would look the same (ie, for example: we will forbid users to control the visibility of blocks on the site, if such blocks exist).
We use variables in theme templates:
- $ user_name - to display the name of the authenticated user;
- $ user_link - to display links related to the user profile;
- $ is_page_authcache - if set to TRUE then all the hooks of this theme template will be saved to the cache.
You can also get acquainted with an example - / sites / all / modules / authcache / modules / authcache_example, which shows how to configure blocks with custom 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 underlies the Authcache module and caches pages better than the built-in Drupal caching. Download the module at the Internet address - http://drupal.org/project/authcache . After downloading, unpack the module in the / sites / all / modules folder. 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 <? Php 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 actions above, 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 are not. Fix this:
- let's download the CSS Gzip module from the page - http://drupal.org/project/css_gzip ;
- Download the JavaScript Aggregator module from http://drupal.org/project/javascript_aggregator ;
- unpack the modules in the / sites / all / modules folder;
- enable modules on the page: Management -> Modules ( http://www.example.ru/admin/build/modules );
- enable CSS and JavaScript compression on the page: Management -> Performance ( http://www.example.ru/admin/settings/performance ), ticking the checkboxes - GZip CSS and GZip JavaScript;
- let's make a change to the .htaccess file located in the root directory of the site (based on the data from the README.txt module of the CSS Gzip module), assign the following code to the <IfModule mod_rewrite.c> and </ IfModule> tags:
### START CSS GZIP ###
# Requires mod_mime to be enabled.
<IfModule mod_mime.c>
# Send any files ending in .gz with x-gzip encoding in the header.
AddEncoding x-gzip .gz
</ IfModule>
# Gzip compressed css files of the type 'text / css'.
<FilesMatch "\ .css \ .gz $">
ForceType text / css
</ FilesMatch>
<IfModule mod_rewrite.c>
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]
</ IfModule>
### End CSS GZIP ###
- save the settings and clear the cache.
If you need to use additional CSS and JavaScript in the skin templates, it is advisable to connect them using the commands:
- drupal_add_css ('path to CSS relative to the root directory of the site');
- drupal_add_js ('path to javascript relative to the root directory of the site');
in order to be optimized (included in one source CSS or JavaScript file) and compressed, along with all other CSS or JavaScript files used on the site.
Optimize Drupal configuration and maintenance
From optimizing Drupal using modules, let's move on to more complex optimization — optimizing the 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 unload the database, especially if thousands of users come to the site per day. By default, sessions are stored for 55 hours, reducing 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);
on:
ini_set ('session.gc_maxlifetime', 86400); // 24 hours (in seconds)
Also in this file, you can shorten the lifetime of cached session pages to 24 hours by changing the line:
ini_set ('session.cache_expire', 200000);
on:
ini_set ('session.cache_expire', 1440); // 24 hours (in minutes)
Lastly, in the same file, we 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 storage time for cookies in the user's browser to 0, then the cookie will be deleted immediately after the Internet browser is closed by the user.
2. Reduce the number of messages logging the work site, stored in the database. On the page: Manage -> Reports and Messages -> Database Reports ( http://www.example.ru/admin/settings/logging/dblog ), set the required maximum of reports stored in the database. These reports are useful for viewing site hacking attempts, so the minimum that you can select is 100 entries. You can view these reports by going to the Manage -> Recent entries in the system log ( http://www.example.ru/admin/reports/dblog ).
3. Configure the execution of regular procedures (cron tasks), since when they are executed, the logs of the site logging messages, outdated cache entries, and other statistical data are cleared. The easiest way to configure automatic startup of regular procedures is to install the module - Poormanscron. Download this module at the Internet address - http://drupal.org/project/poormanscron . We will 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, which estimates the number of visitors to the site 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 some of the modules on this page have checkboxes next to the enable checkboxes - whether this module should be controlled by Throttle or not. Also, some blocks can be regulated by Throttle (Control -> Blocks ( http://www.example.ru/admin/build/block )). Throttle settings are made on the Manage -> Regulator page ( http://www.example.ru/admin/settings/throttle ), where you specify the minimum number of anonymous visitors and the minimum number of registered users to enable site restriction for them. On this page, we also set the probabilistic limiter of the autoregulator to 20%, so that for one out of every 5 requests for issuing a page to the browser to the user, a query is made to the database to determine the load on the site.
Server optimization
Since the site server can work under different operating systems:
- Windows
- Lunux
- Freebsd
then in each case the server optimization settings will be different (i.e., the installation of eAccelerator in Windows and Lunux is very different). Below are only the basic recommendations for server optimization. Details of the recommendations considered only the installation of a PHP accelerator on the Ubuntu 8.04 server, since the PHP accelerator significantly speeds up the work of 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 wget bart.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-eaccelerator = shared
sudo make
sudo make install
Let's edit the php.ini file in the / etc / php5 / apache2 folder, insert the code in the beginning of the file after the [PHP] tag:
; eAccelerator configuration
; Note that it can be installed as a PHP extension or as a zend_extension
; If you are using php you need 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 code above will look like this:
; eAccelerator configuration
; Note that it can be installed as a PHP extension or as a zend_extension
; If you are using php you need 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
; Zend Optimizer configuration
zend_extension = / usr / local / lib / Zend / ZendOptimizer.so
zend_optimizer.optimization_level = 15
Create a cache directory for eAccelerator by running the following commands:
sudo mkdir -p / var / cache / eaccelerator
sudo chmod 0777 / var / cache / eaccelerator
Restart 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 are sent to the browser by the Apache user, and the static content (CSS, JavaScript, photos, etc.) is 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 by 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 settings for interaction 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.
<IfModule mod_expires.c>
# Allow expiration.
ExpiresActive On
# Cache all files for two weeks after access (A).
ExpiresDefault A1209600
# Do not cache dynamically generated pages.
ExpiresByType text / html A1
</ IfModule>
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, it is necessary to prohibit the search for .htaccess files within the root directory of the web server by setting AllowOverride to None:
<Directory />
AllowOverride
...
</ Directory>
Since some modules inside their directories may contain .htaccess files, you should carefully work with this type of optimization, so that if you transfer the contents of all .htaccess files to httpd.conf, do not miss more than one .htaccess file.
5. Install on the server:
- log file analysis system (for example: AWstats),
- server performance monitoring system (for example: Munin);
- system for accounting of 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
on:
query_cache_limit = 1M
query_cache_size = 64M
Then restart MySQL with the command:
/etc/init.d/mysql restart
A cache that is too small is inefficient, and a cache that is too large causes the search for the necessary information in the cache to take a long time. Therefore, we recommend experimenting with the cache size on each specific server and selecting its optimal size.
7. Check - the CPU load, the lack of RAM or disk space and possible overload of the server communication line with the Internet. If it is necessary to place the Database on a separate server, for this we change, the settings for connecting to the database are 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 Amazon C2).
Conclusion
To view server information from Drupal there is a handy module - System information ( http://drupal.org/project/systeminfo ). After it is installed and activated, information about your server can be viewed on 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 Internet browser Firefox, which shows detailed statistics on how to load pages from your site.
An updated version of the article is divided into chapters, available on the website: http://www.mydrupalbook.ru/ .
Author: Elena Tsaplina & Vyacheslav
Source: https://habr.com/ru/post/64286/
All Articles