OpCache + APCu + Static HTML Cache – Server Performance Benchmark
We got cheap Apache VPS server and performed analysis of a common CMS system performance under various cache setups. We wanted to determine how the server performs under plain setup, as well as with the help of bytecode caching with ZEND OpCache, along the user-land APCu and Static (disk-based) HTML caching.
VPS server specifications:
- CPU 0.25 single-core @ 850 MHz (Intel(R) Core(TM) i5-3570 CPU @ 3.40GHz)
- 128 MB RAM + 256 MB SWAP (SSD drive)
- Ubuntu 13.10 64-bit
- Apache 2.4.6
- PHP 5.5.3 (as Apache module)
- MySQL 5.5.37
- OpenVZ container
- 10 Mbit/s Network Interface
- Apache JMeter
- 8 x 100 page requests (main, search, articles, random cycling order)
- 2 VUs concurrency
- Server CPU LOAD: 80 % average (75-85% fluctuating)
Zend OpCache Configuration
- opcache.memory_consumption = 32 MB
- all other settings = factory default
APCu Cache Configuration
- apc.shm_size = 1 Segment 16 MB (mmap memory, locking)
- all other settings = factory default
Static HTML Cache
- Caching only article pages
- Not caching: main page, search pages, category pages, about us pages etc.
SERVER CACHE TYPES EXPLAINED
OpCache will store compiled PHP opcodes into memory, ready to be re-used with new run cycles. OPCode caching puts away extremely slow and costly PHP compiler out of the performance equation. To get a real advantage of OpCache, the more complex the underlying PHP application is, the more effective and accented performance boost will be observed. OpCache comes built-in and enabled by default since PHP 5.5 versions and above.
APCu/Memcache requires root access and they are generally not available on Shared Hosting plans. However, with constant development in Cloud-Linux OS, they might become available one day. However, main requirement for APCu or Memcache to work is the application’s internal support for it, it will not work by simply enabling it on the server’s side, special cache API needs to exist in your application. APCu/Memcache will cache user-land code and reduce MySQL queries for dynamically generated pages, including the login operations and registered users processing. This particular cache is beneficial if you have a large user base in your website.
Static HTML Caching is a special form of buffering and transferring rendered pages into static HTML files. File validity duration is usually user-configurable and it reduces both PHP and MySQL processing to bare minimum! PHP only needs to check requested page against the cached versions of it and if it exists serve it instead of going through all the trouble to render it again. Minimal database calls are made, if any at all. Of course, there is a limit where HTML caching is not recommended or not possible to use: for logged-in users it should never be enabled, since a complete havoc can happen to your dynamic website.
|CACHE SYS SETUP||TOTAL SERVING TIME||TIME
± STD DEV
|1. Server (no caching)||931 sec||Ref. Value||Ref. Value||1143 ± 168 ms||7|
|2. HTML caching (articles)||776 sec||– 155 sec||– 16.7 %||973 ± 294 ms||6|
|3. OpCache caching||420 sec||– 511 sec||– 45.1 %||505 ± 200 ms||4|
|4. APCu caching||929 sec||– 2 sec||– 0.21 %||1145 ± 178 ms||8|
|5. OpCache+HTML||279 sec||– 652 sec||– 70 %||330 ± 251 ms||2|
|6. APCu+HTML||814 sec||– 117 sec||– 12.6 %||959 ± 237 ms||5|
|7. OpCache+APCu||428 sec||– 503 sec||– 54.0 %||483 ± 176 ms||3|
|8. OpCache+APCu+HTML||281 sec||– 650 sec||– 69.9 %||303 ± 219 ms||1|
TOTAL SERVING TIME
time required to serve all requests ( lower is better )
test duration reduction in comparison to plain server setup ( higher abs. values better )
AVERAGE RESPONSE TIME ± STD DEV
average response value + standard deviation ( lower is better )
total score for quick reference ( lower is better )
The result is extra-ordinary! Time to serve 800 pages* requests was reduced from 931 seconds without any caching down to 281 seconds with all three caching techniques in place!
* pages = mixed content simulating random user browsing behavior: main page, search pages, articles, return to main page etc.
There is one peculiarity regarding APCu caching, when it is used alone without OpCache enabled. APCu will internally reduce number of MySQL queries between PHP and MySQL, however, to really shine and show it’s full potential, OpCache must be enabled.
Static HTML caching of dynamic PHP pages will further reduce Server Response Time for additional 10-30 percents. This might not look as significant and much, but keep in mind that our HTML caching was configured to cache only article pages (main website landing page, search pages, other category pages were NOT cached via static/disk system!) which limited it’s scope and effectiveness. However, main purpose of static HTML cache is not only in the reduction of Response Time, but also MySQL connections, as well. This type of cache will put your MySQL server into “sleep” mode, which does not show in above test.
There is no “bad” cache type, or “excessive” caching type here. Every type of cache above targets it’s specific field of “expertise” and definitively helps to reduce server response time, page generation & load times, as well as CPU/SQL loads. In general, cache operates on the expense of the system RAM memory (OpCache, APCu) and HDD/SSD disk space (HTML), which are usually not critical in production environments.
Of course, caching can sometimes have negative impact, both in performance terms and compatibility. Not all plugins/extensions/modules are compatible with, for example, HTML (static) caching type, and you should definitely be careful what/how you use it. Also, APC(u) caching requires careful implementation, using special keys to prevent mix-up of multiple domains content etc.
But all these issues and setbacks aside, it is really up to you which techniques you need and wish to implement. The benefits will be worth it!