| What's an APC?
Alternative PHP cache (APC) is a valid open source Cache tool for PHP, and he is able to cache opcode PHP intermediate code.
PHP APC provides two kinds of caching functions, namely cache opcode (target file), we call it apc_compiler_cache. It also provides interfaces for PHP developers to host user data in memory, which we call Apc_user_cache. We are here mainly to control the configuration of PHP-APC.
Installing the PHP APC
As a test environment, we use CentOS5.3 (2.6.18-128.EL5PAE) + Apache2.0 (prefork) + php5.2. We can go to pecl APC download apc-3.0.19.tgz # TAR-XZVF apc-3.0.19.tgz
#cd APC-3.0.19
#/usr/bin/phpize
#./configure--ENABLE-APC--enable-mmap--enable-apc-spinlocks--disable-apc-pthreadmutex
#make
#make Install
Note: We support mmap and use spinlocks spin lock. Spinlocks is recommended by Facebook and is a locking mechanism recommended by APC developers.
PHP APC Configuration Parameters
If you use the same system environment as my test environment, you can create the file Apc.ini in the/ETC/PHP.D directory, and the related configuration is written to the/etc/php.d/apc.ini file. Here, we pick out some of the commonly used configurations and discuss them. Put the relevant configuration together to explain. Apc.enabled=1
The default value of apc.enabled is 1, you can set the 0 disable APC. If you set it to 0, also comment out the extension=apc.so (this saves memory resources). Once the APC feature is enabled, opcodes to shared memory is cached. Apc.shm_segments = 1
Apc.shm_size = 30
Since APC caches data in memory, it is necessary to qualify it for memory resources. These two configurations allow you to limit the amount of memory space an APC can use. APC.SHM_SEGMENTS Specifies the number of shared memory blocks, while apc.shm_size specifies the amount of shared memory space, in M. Therefore, the amount of memory allowed to be used by APC should be apc.shm_segments * apc.shm_size = 30M. You can adjust the size of a shared memory space. Of course, the maximum shared memory value is limited by the operating system, that is, the/proc/sys/kernel/shmmax size cannot be exceeded. Otherwise, the APC will fail when it creates shared memory. When the apc.shm_size reaches the upper limit, you can set the apc.shm_segments to allow the APC to use more memory space. We recommend that if you call APC use of memory space, the first Test filter apc.shm_size, after the test filter apc.shm_segments. The specific values can be planned and adjusted according to the apc.php monitoring situation. It is worth noting that each adjustment requires a reboot of the httpd daemon so that the Apc.so module can be reloaded. Following the httpd daemon boot, the apc.so module is loaded. apc.so load initialization, allocates memory at a specified size through a MMAP request, that is, apc.shm_size * apc.shm_segments. Also, the anonymous memory mapping is used to provide a "large", 0-filled memory for APC management by mapping a special device,/dev/zero.
To verify the above statement, we commented out the Apc.ini configuration and wrote the following PHP script to observe the allocated memory space initialized by the apc.so module.
<?php
@file: apc_load.php
if (!extension_loaded (' APC ')) {
DL (' apc.so '); #加载apc. So module
Echo Posix_getpid (); #//output The PID of the current process, I here output is 14735
Ob_flush ();
Flush ();
Sleep (3600); #让进程进入休眠状态. In this way, we can observe the memory allocation
}
?>
#strace-P ' cat/var/run/httpd.pid '
Open ("/var/www/html/apc_load.php", o_rdonly) = 13
...
MMAP2 (NULL, 31457280, prot_read| Prot_write, map_shared| Map_anonymous,-1, 0) = 0xb5ce7000
...
Nanosleep ({3600, 0},
The red part, we can see. 30M (31457280/1024/1024) memory space was allocated through the MMAP system kernel call. prot_read| Prot_write indicates that the memory space is available for reading and writing. Map_shared indicates that the memory space is shared with other processes, that is, other processes can also read and write, and we can manage that block of memory through apc.php to benefit from this setting. The map_anonymous represents an anonymous mapping. Where Fd=-1 is ignored because of the special device/dev/zero that is mapped here. The last 0 indicates no offsets. We can also see the details of the block memory through the process image file
#cat/proc/14735/smaps b5ce7000-b7ae7000 Rw-s 00000000 00:08 633695/dev/zero (Deleted)
size:30720 KB
Rss:44 KB
shared_clean:0 KB
shared_dirty:0 KB
private_clean:0 KB
Private_dirty:44 KB
It is easy to find that the starting address 0xb5ce7000 is the same as the address returned by the MMAP system kernel call above. The block memory is readable and writable by RW and shared with other processes S. The/dev/zero is the mapping file, which has a 633695 node. Where size represents the memory space that the process can use, and RSS represents the actual allocated memory space, and as Private_dirty can see, the actual allocated 44kb of memory is allocated by the current process itself. Apc.num_files_hint = 1000
Apc.user_entries_hint = 4096
These two configurations specify how many cache entries the APC can have. Apc.num_files_hint explains how many files you estimate might be opcodes need to be slowed down, that is, how many Apc_compiler_cache entries can be made. In addition, Apc.user_entries_hint indicates how many Apc_userdata_cache entries you might expect to be cached. This value can be set even smaller if you do not use Apc_store () to cache user data in your project. That is, the sum of Apc.num_files_hint and Apc.user_entries_hint determines the number of objects that the APC allows for maximum cache of object entries. Setting these two values accurately can get the best query performance. Of course, if you don't know how much caching to make (cache object instances), you don't have to modify these two configurations.
The apc.user_entries_hint will use the Apc_store () entry to estimate its value according to the actual development of the project. In contrast, Apc.num_files_hint can estimate its size more easily by the find command. For example, if our web root is/var/vhosts, use the Find command below to roughly count the number of current apc.num_files_hint.
#find/var/vhosts \ (-name "*.php"-or-name "*.inc" \)-type F-print
1442 Apc.stat = 1
Apc.stat_ctime = 0
These two parameters are related only to the Apc_compiler_cache cache and do not affect Apc_user_cache. As we mentioned earlier, the object that it caches is the corresponding opcodes (target file) of PHP source file one by one (Apc_complier_cache). PHP source files are stored on the disk device, corresponding to the opcodes target file location memory space (shared memory), then when the PHP source file is modified, how to notify the update of the memory space opcodes? After each request is received, APC will check the last modification time of the open PHP source file, if the last modification time of the file is inconsistent with the corresponding memory space cache object record, the APC thinks that the opcode target file (cache object) that is stored in the memory space has expired. ACP clears the cached object and saves the newly resolved opcode. We are concerned that even if no PHP source files are updated, each time an HTTP request is received, the APC requests the system kernel to call stat () to obtain the final modification of the PHP source file. We can set the Apc.stat to 0 and ask the APC not to check to see if the corresponding PHP source file for opcodes is updated. This allows for the best performance and we recommend doing so. However, it is a bit bad that once a PHP source file has been updated, you need to restart the httpd daemon or call the Apc_cache_clear () function to empty the APC cache to ensure that the PHP source files are consistent with the opcodes cached in the memory space.
<?php
Define (' Rootp ', DirName (__file__). '/');
Include (ROOTP. ' i1.php ');
Require (ROOTP. ' i2.php ');
Include_once (ROOTP. ' i3.php ');
Require_once (ROOTP. ' i4.php ');
Require (ROOTP. ' i5.php ');
Include (ROOTP. ' i6.php ');
?>
# strace-e trace=file-p ' Cat/var/run/httpd.pid '
GETCWD ("/var/www/html", 4096) = 14
Stat64 ("/var/www/html/i1.php", {st_mode=s_ifreg|0644, st_size=39, ...}) = 0
Stat64 ("/var/www/html/i2.php", {st_mode=s_ifreg|0644, st_size=39, ...}) = 0
Lstat64 ("/var", {st_mode=s_ifdir|0755, st_size=4096, ...}) = 0
Lstat64 ("/var/www", {st_mode=s_ifdir|0755, st_size=4096, ...}) = 0
Lstat64 ("/var/www/html", {st_mode=s_ifdir|0755, st_size=4096, ...}) = 0
Lstat64 ("/var/www/html/i3.php", {st_mode=s_ifreg|0644, st_size=39, ...}) = 0
Open ("/var/www/html/i3.php", o_rdonly) = 12
Stat64 ("/var/www/html/i3.php", {st_mode=s_ifreg|0644, st_size=39, ...}) = 0
Lstat64 ("/var", {st_mode=s_ifdir|0755, st_size=4096, ...}) = 0
Lstat64 ("/var/www", {st_mode=s_ifdir|0755, st_size=4096, ...}) = 0
Lstat64 ("/var/www/html", {st_mode=s_ifdir|0755, st_size=4096, ...}) = 0
Lstat64 ("/var/www/html/i4.php", {st_mode=s_ifreg|0644, st_size=39, ...}) = 0
Open ("/var/www/html/i4.php", o_rdonly) = 12
Stat64 ("/var/www/html/i4.php", {st_mode=s_ifreg|0644, st_size=39, ...}) = 0
Stat64 ("/var/www/html/i5.php", {st_mode=s_ifreg|0644, st_size=39, ...}) = 0
Stat64 ("/var/www/html/i6.php", {st_mode=s_ifreg|0644, st_size=39, ...}) = 0
ChDir ("/tmp") = 0
# strace-e trace=file-p ' Cat/var/run/httpd.pid '
GETCWD ("/var/www/html", 4096) = 14
Open ("/var/www/html/i3.php", o_rdonly) = 12
Open ("/var/www/html/i4.php", o_rdonly) = 12
ChDir ("/tmp") = 0
Compared to visible, when apc.stat=0, save a lot of system kernel calls, we do not see the system kernel call Stat64. Among them, i3.php and i4.php are PHP's include_once and require_once function calls, which are given to the Fstat () system kernel call to check if the file is open. From the performance point of view, require is better than require_once performance. The Setting Apc.stat_ctime is very significant. If the Apc.stat_ctime value is 1 o'clock, the mtime time of the cached object is replaced by the CTime of the PHP source file only when the PHP source file is created (CTime) is greater than the last modification time (mtime) of the PHP source file. Otherwise the mtime of the cached object is still recorded as the mtime of the PHP source file. This is to prevent the mtime of the PHP source file from being refreshed through tools such as CVS, SVN, or rsync, which can cause APC to determine if the cached object has expired by CTime the creation time of the PHP source file. We recommend that you keep the default value, that is, Apc.stat_ctime = 0 The apc.ttl=0
Apc.user_ttl=0
The lifecycle of the cached object. Where the TTL represents time to Live, it means that the cached object will be purged after the specified period. 0 of which means never expiring. As we mentioned earlier, the entries that the APC can cache are limited, and if you never expire the TTL setting, the cache will fail when the cache entry is full or the cache space is insufficient.
where Apc.ttl acts on Apc_compiler_cache. When the Apc.ttl is greater than 0 o'clock, each request will compare the difference between the request time and the last request time is greater than apc.ttl, if greater than Apc.ttl, the cache entry will be expired, will be cleaned up.
The interesting thing is Apc.user_ttl, which mainly works on the Apc_user_cache cache. We know that this type of cache is a cache object created by Apc_store ($key, $var, $ttl = 0). We are more concerned about the similarities and differences between the $ttl specified in the function Apc_store () and the Apc.user_ttl set in php.ini. Because they also work on the Apc_userdata_cache cache. After analysis, we know: the basis for determining Apc_user_cache cache expiration is that when the Apc.user_ttl is greater than 0 and the difference between this HTTP request time and the previous HTTP request time is greater than Apc.user_ttl, the corresponding cache entry is considered expired; User.data.ttl ($ttl specified in the PHP function Apc_store ()) is greater than 0, and the difference between this HTTP request time and the cache object creation time CTime is greater than User.data.ttl, the cache entry is also considered to have expired and will be purged.
We recommend that if your project is more stable, and the Apc.stat is set to 0. At the same time apc.shm_size, Apc.num_files_hint set reasonable, Apc.ttl recommended set to 0. That is, the apc_compiler_cache will never be recycled until the httpd daemon is restarted or the function apc_cache_clear () clear cache is called. As for Apc.user_ttl, the recommendation is set to 0, when the developer calls the Apc_store () function, set $ttl to specify the lifecycle of the cached object. The apc.slam_defense=0
Apc.write_lock=1
apc.file_update_protection=2
explains the three configurations together because they are very similar in meaning. Where Apc.file_update_protection is best understood, its unit is the time unit seconds. If the current HTTP request time is the best time to modify the PHP source file mtime is less than apc.file_update_protection time, APC will not cache the PHP source file corresponding to the opcodes, until the next visit, And the access time and the PHP source file last modified time is greater than apc.file_update_protection time, the corresponding opcodes will be cached to the shared memory space. The advantage of this is that it is not easy for users to access the source files you are modifying. We recommend that in the development environment, this value can be set to a greater extent, but in the operating environment, we recommend that you keep the default value.
When you have a large number of concurrent Web sites, it is possible to cache the same opcodes at the same time as multiple subprocess fork by the HTTP daemon. Passing apc.slam_defense can reduce the likelihood of this happening. For example, when the Apc.slam_defense value is set to 60, when the opcodes is encountered, there are 60 times every 100 times that are not cached. For Web sites with a small amount of concurrency, we recommend that the value be set to 0, and we can adjust the value appropriately according to statistics for a highly concurrent site. Apc.write_lock is a Boolean value, when the value is set to 1, when multiple processes simultaneously cache the same opcodes, only if the first process cache is valid, the other is invalid. By Apc.write_lock setting, it effectively avoids the emergence of cache write competition. apc.max_file_size=1m
Apc.filters = NULL
Apc.cache_by_default=1
These three configurations are put together because they are all used to limit caching. Where apc.max_file_size indicates that if the PHP source file exceeds 1M, the corresponding opcodes is not cached. Instead, apc.filters specifies a list of file filters, separated by commas (,). When Apc.cache_by_default equals 1 o'clock, files that match the file names specified in the Apc.filters list are not cached. Instead, Apc.cache_by_default equals 0 o'clock, caching only files that match the files specified in the Acp.filters list.
Summarize
1, the use of spinlocks lock mechanism, to achieve the best performance.
The 2,APC provides apc.php for monitoring and managing the APC cache. Don't forget to change the administrator name and password
3,APC By default creates shared memory by Mmap Anonymous mappings, which are stored in this "large" memory space. This shared memory is managed by the APC itself
4, we need to adjust the values of apc.shm_size, Apc.num_files_hints, apc.user_entries_hint by statistics. Until the best
5, OK, I admit Apc.stat = 0 can achieve better performance. Anything I can do is acceptable.
6,php predefined constants, you can use the apc_define_constants () function. However, according to the APC developers said PECL HiDef performance better, throw a different define it, it is inefficient.
7, Function Apc_store (), for the system settings such as PHP variables, the lifecycle is the entire application (from the httpd daemon until the httpd daemon shutdown), the use of APC than memcached will be better. Must not go through the Network Transport Protocol TCP.
8,APC is not suitable for user data that is frequently changed through function Apc_store () caching, there are some strange phenomena.
9.APC module to speak. As an APC author, his ideas should be of great reference value.
APC'll probably be 20-30% faster, but if your are to it writing it can frequently cause. The APC cache is best for things this change very rarely. And by very rarely I mean days, not hours or minutes.
Because of the way APC does an anonymous file-backed mmap where I unlink the file in startup to get Process-death protecti On, it isn ' t easy to get in the cache from a separate standalone command line script. That can is solved by mmap ' ing slightly differently, but in the default Config your approach ' t won.
-rasmus
This means that APC is not suitable for frequently written occasions, and you are best to use him only to save things that won't change for a few days. Otherwise, there is no such thing as a puzzling question.
In the previous application, I did have the APC used in frequent writing occasions, occasionally memory exhaustion, which caused all the HTTP request card death, the form of an uncontrollable whole server. So at the moment I only use APC to cache opcode PHP code, not explicitly called in the program, is a peaceful. |
