
Hello.
In the previous article , we learned about configuring the nginx + apache bundle in the hosting mode and the dotdeb repositories.
In this article we will learn about the configuration of backend: PHP, MySQL.
In the PHP part, we will introduce the following topics:
- general PHP setup
- the correct PHP + Postfix setting for sending emails via the internal SMTP server using the mail () function,
- setting up caching of code and / or data based on APC.
')
As part of MySQL, I will try to reveal the basic points of improving performance, because by default the MySQL server is configured very inefficiently.
Who are interested, welcome under the cat
Information:
I myself am not a database tuning pro. There are really cool peppers for that, and they cruelly torment the databases in different configurations on test stands and on real databases for maximum performance for specific tasks. This article is easier. I estimated the basic configuration by eye + corrected all the problems that I saw in
SHOW VARIABLES . It feels like after normal tuning the main resource began to work faster than before.
Again, from the
previous article, we give a diagram of the architecture of the system being configured, for a visual representation of server resources
(click-through)
PHP 5.3.18 setup
In the beginning, as always. I ask my configs php + apc:
yadi.sk/d/0OuPvlBS0t01O- General PHP setupIn general, I did not find anything interesting in the php.ini file. However, there is something to pay attention:
It is very important if you take packages from dotdeb:- date.timezone = Europe / Moscow - the time zone must be set, otherwise the date function generates a bunch of warnings. I don’t know why, but this problem appeared either after updating PHP to a new version, or because of the dotdeb repositories, which are compiled a little differently from the Debian ones. In this case, the time zone of Moscow is set.
- VERY IMPORTANT: session.save_path = "/ var / lib / php5" - it must be set this way! According to the debian standard, this is where the sessions should be. I do not know why, but in the debian assembly this variable is not set. It can be seen it is already collected by default. Dotdeb by default writes sessions to the / tmp directory, which is completely wrong. Please pay attention to the configuration of partitions on the server: 25G /, 20G swap, 100G / var, ~ 800G / home. This partition configuration was calculated for debian. As a result of this uncertainty, I had a completely unexpected accident on the production server! as a result, customers could suffer. The accident occurred due to the unexpected clogging of the section /. The problem was found and promptly fixed. For some reason, the garbage session collector did not work in the / tmp directory, probably due to access rights. ( UPD from: kamazee : this is due to the debian way of building legacy sessions )
Performance and resources:
- max_execution_time = 30 - execution time of scripts, left by default. On the one hand, the scripts should not be infinitely executable, so there should be a restriction. On the other hand, it can be assumed that usually there are no infinite cycles, so the constraint does not need to be clamped. For those who use potential infinite cycles, it is recommended to tighten this setting harder
- memory_limit = 128M is what the maximum amount of memory a script can consume. PHP will not allocate more memory than specified in this setting. This setting is specified depending on the tasks executed on the server. For a more accurate calculation of resources, you should tighten this parameter as much as possible and try to write software as best you can.
- post_max_size = 70M - this parameter must be less than the total amount of allocated memory in memory_limit. As we have already indicated in the scheme, at the frontend level, nginx will not miss the request body of more than 64M. This parameter is taken with overlap, for we read further.
- upload_max_filesize = 64M - the maximum file size that can be uploaded is verified for the nginx configuration, therefore it is meaningless to set it higher. It is better to overlap, so as not to get such a problem with an empty POST
- When setting up PHP, I want you to pay attention to the sequence of overlaps: memory_limit - post_max_size - upload_max_filesize. One should be more than the other in the specified sequence, then everything will work stably.
- max_file_uploads = 20 - the number of files that can be transferred in one request. This parameter should be solved for everyone. For example, it was calculated that the average photo will weigh no more than 3M, it turns out about 20 photos at a time. On the server, you can do a mass upload of photos / documents. I do not know how in practice it should be implemented, but in theory it should work.
Hiding PHP presence
- session.name = SESSID changed from PHPSESSID to SESSID, for greater secrecy.
- expose_php = Off - disables headers that indicate that PHP is running on the server, not shining on what you are worth.
- user_agent = "EXAMPLE-SERVER" is an interesting thing. If you make a spider in PHP, for example, then this will be the user-agent header that will be sent to the remote server when you request any data.
- the rest is left unchanged
A few words about the error output (+ Hiding the presence of PHP 2):
- error_reporting = E_ERROR (E_ERROR | E_WARNING amendment from truezemez, see the comments) - so that production doesn’t pay much attention to recording various problems, turned off this option. Left only the most critical. On the other hand, if you have high-quality software, then you should set the maximum error / problem output E_ALL | E_STRICT to find problems in real conditions
- display_errors = Off is a very common mistake of webmasters , please turn off the display of errors on the screen, users find it very unpleasant to look at it, and hackers are just delicious!
- log_errors = On - naturally, if we do not output logs, they must be written!
- the rest is left unchanged
- Setting up cache APC (version 3.1.9):APC caches opcodes, in addition, it can cache data. I use APC for the reason that Yii recommends it. In Yii, there are already written classes for working with this cache. Other casher did not consider and did not compare for the above reasons.
The file config is empty by default, all values ​​are set by default. In particular, 32M is allocated for caching - enough for the code, not for the data.
In the file specified by me, you should definitely pay attention to the following:
- apc.shm_size = 512M - in debian / dotdeb APC is compiled with MMAP Support. Accordingly, the apc.shm_segments parameter is not taken into account and this setting should only be used.
- apc.file_update_protection = 3 - the higher this parameter, the fewer times the APC checks if the file with the code has changed. Specified in seconds. If you rarely update the code on the server, then this parameter can be set to 60
- There are other settings that were left by default.
- Setting up the mail () function:Out of the box, the mail () function should not work. In order for it to work, a properly working SMTP mail server is needed. In the previous article we installed such a server.
It is worth setting to pay attention to the following things:
- sendmail_path = / usr / sbin / sendmail -t -i -fno-reply@example.com - using this command, we correctly configure the headers to be sent. Correct headers are needed to avoid spamming. Regarding the correct headers, please read my article: Literate setting up the mail sending server for PHP scripts, setting up the mail () function (the article is of course a terrible mess, but it still explains what's what, in time I will try to write a manual in the spirit of this series of articles)
- mail.add_x_header = Off - as always, we do not shine with what we don’t need
MySQL 5.5.28 Setup
While reading the documentation I stumbled upon the fad settings at the level of fiction. People deliberately start tests to squeeze out of the database maximum performance of up to 30 percent on certain settings and on a certain hardware.
We will not have this. We will simply follow common sense and documentation.
Welcome to configs:
yadi.sk/d/T1ov6qAF0t82yConfiguration file structure:
- /my.cnf - the main configuration file itself, in which the main directory settings are recorded and which loads other configuration files
- /conf.d/.keepme is an uncomplicated name, as if saying that you should not delete it. It was left by default.
- /conf.d/mysqld_base_perfomance.cnf - tuning the overall database performance. These settings are not associated with any type of storage used.
- /conf.d/mysqld_common.cnf - some common settings that could not be grouped.
- /conf.d/mysqld_innodb.cnf - InnoDB Storage Settings
- /conf.d/mysqld_log.cnf - logging settings
- /conf.d/mysqld_myisam.cnf - MyISAM Storage Settings
- /conf.d/mysqld_query_cache.cnf - setting query caching
- /conf.d/mysqld_thread.cnf - setting threads
In the my.cnf file, please pay attention to the following settings.
- max_connections = 300 - increased the number of connections, equal to 150 * 2 based on the fact that each PHP process can create 2 independent connections.
- max_allowed_packet = 2M - increased the size of the transmitted packet
- datadir = / home / mysql - during configuration, a separate directory in / home for mysql was made with protection from access by other users except mysql. This is done to transfer data from / var / lib / mysql (if I'm not mistaken) to the / home partition - the largest disk partition on the server, where all the data is stored.
- SHOW VARIABLESTo view what operations the database performs,
SHOW VARIABLES was created. With it, you can learn about such things as the number of input-output operations, the number of hits in the cache, the number of sorts through files and more. I advise you to review.
In the configurations, next to each setting, affecting the performance, there is a link (see) to which parameter
SHOW VARIABLES should be viewed. For all other details, please refer to the documentation.
Some settings that should be noted:
- /conf.d/mysqld_thread.cnf thread_cache_size / thread_concurrency - set by the number of cores.
- mysqld_base_perfomance.cnf tmp_table_size = 8M - if you have many sorts through temporary files, then you need to increase this parameter. Do not forget that you need to remember the capabilities of the server. In our case, 300 connections at 8M = 2.4G at the peak, we will spend on sorting in the temporary table.
- mysqld_query_cache.cnf query_cache_size = 256M - do not abuse the size of the query cache, in this case it is no better, unlike some other database settings. 256M is enough - 8 times the default value. Details in the documentation
- mysqld_myisam.cnf concurrent_insert = ALWAYS - I was pleasantly surprised when I learned that there is a competitive insert in MyISAM, I reviewed my attitude to this table.
- mysqld_myisam.cnf key_buffer_size = 256M - if you use a lot of MyISAM tables, then this parameter should be larger, otherwise it is better to increase it to 256, so that your soul would be calm.
- Important: mysqld_innodb.cnf innodb_buffer_pool_size = 5G is the most important parameter, the default InnoDB tables are not configured at all, to work on even though small servers. If you do not configure this parameter, then we will get a fierce load on the disk subsystem. Ideally, this parameter is recommended to keep a little bit larger than the total size of all databases.
- mysqld_innodb.cnf innodb_log_buffer_size = 32M is the same, only for logs of InnoDB tables. (These are transaction logs, not the usual logs configured in the mysqld_log.cnf file)
- It is very interesting to read: mysqld_innodb.cnf innodb_buffer_pool_instances = 1 - there are whole battles for this option on the verge of fiction. Here is a link where you can find information that is well connected to each other: dimitrik.free.fr/blog/archives/2012/10/mysql-performance-innodb-buffer-pool-instances-in-56.html . I did not fully understand what they were writing there, I will not misinform. I read, looked at the graphics, did not take risks, and left 1.
All other parameters can be found in the configuration files.
PS: Wow damn poured. Hope not too sloppy? If at least 70% managed to convey, then it is good.
If this article is to taste, then I am going to write about the mail () + postfix + dkim setting in the spirit of a series of articles. Then write about setting permissions on the server. Then write about the different experience of owning a server at your disposal, in the same place we will try again to give the server scheme and paint the main nodes and memory consumption and I think I will also stuff a script for server deployment and server management (add and delete users at the level) and explain all the nuances accordingly associated for example with the naming standards adopted by me. At the end of the entire cycle of articles, I would like to introduce my home server, which, by the way, you can easily scale by adding new virtual machines and laptops + virtual machines to the “rack” =). All settings are first tested on this small server before they get to the working servers.
Thanks for attention.
UPD 2012.11.26 13:30 - Judging by the karma, at this stage we will finish writing articles. But in vain, because nowhere on the Internet you will find an overview of the full cycle of setting up a web server and sharing your experience, just a bunch of different author manuals. Thank you for your attention, I wish you all good luck.