PHP Caching solutions and performance
| PHP caching solutions | |
|---|---|
| Different caching solutions and their performance on Semantic MediaWiki. | |
| Keywords | |
| Table of Contents | |
You can run a MediaWiki wiki with "only" the core functionality on very modest hardware and software and it will be reasonably "fast". Once you start adding the extensions you need your wiki will get a bit slower but depending on the hardware used you probably won't even notice this. There are ways to make your wiki faster and once your there you don't want to go back. This page tries to describe some of the basics on how to make your wiki faster. This page is not the holy grail of "wiki performance" but it will get you going.
A typical SMW wiki could be one that holds tons of data, with lots of templates in combination with a lots of parser functions that drive the "PARSER" nuts. To please your users so they can maintain their data with ease so you are also using SF with multiple instance templates. In such a case you can speed up your Wiki using one of the solutions below. It is wise to try out different configurations and setups on a test server. If you try to setup and test the options below on a "life" server you are asking for trouble.
When using SMW your web server will be configured to use PHP. Because PHP is a scripting language your server needs to compile the PHP code first and then do its magic and show you the page requested. While you may think it does that rather fast in most cases you could increase your servers performance a lot. Most of the PHP code for MW and SMW will not change, it is static so what PHP caching does is storing the compiled PHP code and execute that directly the next time you request that page which holds the code. There are several solutions that all work and have there pros and cons.
XCache[edit]
XCache is being developed by the "people" of the lighttpd webserver software.
Pros:
- Supports object caching in Mediawiki
- Reliable and stable
- Well maintained and documented
- Multi OS support
- Is fast in combination with object caching.
Cons:
- Object caching not working when PHP is running in CLI mode.
- Is relatively "slow" when object caching is not used.
Installing XCache:
How to install and setup php.ini please read the documentation.
php configuration[edit]
Below is a working example configuration for php used on a SMW wiki. Depending on how many wiki's you have and/or how many extensions you use you need to tune the memory size used. You can do this via the monitoring page provided.
[xcache-common]
;; non-Windows example:
extension = xcache.so
;; Windows example:
;;extension = php_xcache.dll
[xcache.admin]
xcache.admin.enable_auth = On
xcache.admin.user = "admin"
; set xcache.admin.pass = md5($your_password)
; login use $your_password
xcache.admin.pass = "e71c4731a07e00083ed57c9c9c44eb58"
[xcache]
; ini only settings, all the values here is default unless explained
; select low level shm implemenation
xcache.shm_scheme = "mmap"
; to disable: xcache.size=0
; to enable : xcache.size=64M etc (any size > 0) and your system mmap allows
xcache.size = 32M
; set to cpu count (cat /proc/cpuinfo |grep -c processor)
xcache.count = 4
; just a hash hints, you can always store count(items) > slots
xcache.slots = 8K
; ttl of the cache item, 0=forever
xcache.ttl = 0
; interval of gc scanning expired items, 0=no scan, other values is in seconds
xcache.gc_interval = 0
; same as aboves but for variable cache
xcache.var_size = 16M
xcache.var_count = 4
xcache.var_slots = 8K
; default value for $ttl parameter of xcache_*() functions
xcache.var_ttl = 0
; hard limit ttl that cannot be exceed by xcache_*() functions. 0=unlimited
xcache.var_maxttl = 0
xcache.var_gc_interval = 300
; mode:0, const string specified by xcache.var_namespace
; mode:1, $_SERVER[xcache.var_namespace]
; mode:2, uid or gid (specified by xcache.var_namespace)
xcache.var_namespace_mode = 0
xcache.var_namespace = ""
; N/A for /dev/zero
xcache.readonly_protection = Off
; for *nix, xcache.mmap_path is a file path, not directory. (auto create/overwrite)
; Use something like "/tmp/xcache" instead of "/dev/*" if you want to turn on ReadonlyProtection
; different process group of php won't share the same /tmp/xcache
; for win32, xcache.mmap_path=anonymous map name, not file path
xcache.mmap_path = "/tmp/xcache"
; Useful when XCache crash. leave it blank(disabled) or "/tmp/phpcore/" (writable by php)
xcache.coredump_directory = ""
; Windows only. leave it as 0 (default) until you're told by XCache dev
xcache.coredump_type = 0
; disable cache after crash
xcache.disable_on_crash = On
; enable experimental documented features for each release if available
xcache.experimental = Off
; per request settings. can ini_set, .htaccess etc
xcache.cacher = On
xcache.stat = On
xcache.optimizer = Off
[xcache.coverager]
; enabling this feature will impact performance
; enabled only if xcache.coverager == On && xcache.coveragedump_directory == "non-empty-value"
; per request settings. can ini_set, .htaccess etc
; enable coverage data collecting and xcache_coverager_start/stop/get/clean() functions
xcache.coverager = Off
xcache.coverager_autostart = On
; set in php ini file only
; make sure it's readable (open_basedir is checked) by coverage viewer script
xcache.coveragedump_directory = ""
LocalSettings.php configuration[edit]
If you want to make use of the object caching supported by XCache you need to enable this in your localSettings.php file. Because object caching does not work with PHP in CLI mode you could add the code below which checks if PHP is running in CLI mode and when it does it will revert to CACHE_NONE instead of using the object caching from XCache. There are probably better solutions but this one works and is simple.
if(php_sapi_name() == "cli") {
$wgMainCacheType = CACHE_NONE;
} else {
$wgMainCacheType = CACHE_ACCEL;
}
Zend Opcache[edit]
Is included in PHP 5.5 and later. For documentation read this. To monitor Zend OPCache performance you could use one of the following solutions, Opcache-Status by Rasmus Lerdorf or opcache-gui by amnuts.
Pros:
- Part of PHP 5.5
- Enabled by default. Easy to setup
- Stable
Cons:
- You need to update PHP to at least 5.5
- No object caching
php configuration[edit]
; configuration for php ZendOpcache module
; priority=05
zend_extension=opcache.so
;; Windows example:
; extension = C:\Program Files\PHP\ext\php_opcache.dll
; Determines if Zend OPCache is enabled
opcache.enable=1
; Determines if Zend OPCache is enabled for the CLI version of PHP
opcache.enable_cli=1
; The OPcache shared memory storage size.
opcache.memory_consumption=64
; The amount of memory for interned strings in Mbytes.
opcache.interned_strings_buffer=8
; The maximum number of keys (scripts) in the OPcache hash table.
; Only numbers between 200 and 100000 are allowed.
opcache.max_accelerated_files=8000
; The maximum percentage of "wasted" memory until a restart is scheduled.
opcache.max_wasted_percentage=5
; When disabled, you must reset the OPcache manually or restart the
; webserver for changes to the filesystem to take effect.
opcache.validate_timestamps=1
; How often (in seconds) to check file timestamps for changes to the shared
; memory storage allocation. ("1" means validate once per second, but only
; once per request. "0" means always validate)
opcache.revalidate_freq=60
; If enabled, a fast shutdown sequence is used for the accelerated code
opcache.fast_shutdown=1
HHVM[edit]
HHVM stands for Hip Hop Virtual Machine. When you have your web server running on Linux and especially Ubuntu this is one of the faster solutions. It basically does the same thing as the others but it uses JIT (Just In Time) compiler which compiles the PHP code to machine language. If you are interested in the details on why and how read this on the HHVM webside. When you are using Linux as an OS to run your wiki this is an option you want to take a look at. Also the combination with SMW seems to be working very well.
Pros:
- Very fast
- Supports object caching in Mediawiki[1]
- Easy to setup
Cons:
- Initial "cold start" is relatively slow
- It is x86-64 only
- Runs on Linux only (Ubuntu)
- Is a magic "black box"
- HHVM is faster with "optimized" PHP code. Extensions may need an update to take the full advantage
- Object caching not working when PHP is running in CLI mode.
- No encrypted email out of the box! (cee bug 1647).
Installing HHVM:
How to install please read the documentation on the HHVM site.
LocalSettings.php configuration[edit]
You can make use of the APC[1] object caching when using HHVM you need to enable this in your localSettings.php file. Because object caching does not work with PHP in CLI mode you could add the code below which checks if PHP is running in CLI mode and when it does it will revert to CACHE_NONE instead of using the object caching from APC. There are probably better solutions but this one works and is simple.
if(php_sapi_name() == "cli") {
$wgMainCacheType = CACHE_NONE;
} else {
$wgMainCacheType = CACHE_ACCEL;
}
Conclusions on measurements below[edit]
These "conclusions" are not for "high traffic" wikis that get 1000 hits per second. They are for "low traffic" wikis where you and some other people browse and edit a wiki all at the same time. High traffic Wikis use the same software but there is a lot more tuning to do to be able to serve that many people at the same time. That is not the scope of this document. The measurements taken for this test are done by pressing F5 multiple times until you have a average number that makes sense, rounded to 0.05 s, noting smaller. But fractions of a second do count on high traffic sites. No science just common sense.
- When you have very powerful hardware which you are the soul user of you will probably not notice the difference between not doing any PHP caching and using PHP caching.
- When you are not using PHP caching on your current server which is relatively "old" you can make it as fast or faster with PHP caching compared to a new server without PHP caching.
- When navigating trough a PHP cached wiki there is no real noticeable difference between the Intel i7 and the AMD A8 systems tested in this document. This is because of browser caching and other magic happening.
- PHP caching has more noticeable impact on "older" (slower) hardware.
- HHVM with object caching[1] enabled is by far the fastest solution.
- There is almost no performance penalty for a SMW wiki with HHVM with enabled object caching.
- Editing really shines on HHVM with object caching.
- When using XCache with object caching enabled you can even run your SMW wiki on a Raspberry PI. It will become as fast as your really "old" server that does not use any PHP caching. It is a shame HHVM is 64 bits only.
Measurements[edit]
Browser used to measure the times was Chromium, Version 39.0.2171.65 on Ubuntu Desktop 14.04 (64-bit). The browser cache was enabled and pages where refreshed with F5. All times are average load times. The measurements where done on 4 different configurations. On all wikis the WikiEditor was enabled and used.
Hardware & Software used[edit]
| Intel i7 | |
|---|---|
| Hardware | Software |
|
|
| AMD A8-3850 | |
| Hardware | Software |
|
|
| AMD A8-3850 (Server is running in VirtualBox version 4.3.10. Host is running on Ubuntu Desktop 14.04 LTS.) | |
| Hardware | Software |
|
|
| Raspberry PI 2 Model B | |
| Hardware | Software |
|
|
Default MW[edit]
What does it mean:
Enabled extensions:
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
[edit]
What does it mean:
Enabled extensions:
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
See also[edit]
Help page on caching.
References[edit]
