OpCache + APCu + Static HTML Cache Server Performance Benchmark

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.

speedometar-tahometar

TechnoBlog.org – Server Cache Benchmark

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

Test specifications:

  • 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.

 

RESULTS TABLE

CACHE SYS SETUP TOTAL SERVING TIME TIME
REDUCTION
[sec]
TIME
REDUCTION
[%]
AVERAGE RESPONSE
TIME
± STD DEV
FINAL SCORE
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

TABLE LEGEND:

TOTAL SERVING TIME
time required to serve all requests ( lower is better )

TIME REDUCTION
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 )

FINAL SCORE
total score for quick reference ( lower is better )

 

RESULTS ANALYSIS

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.

Server Benchmark Results Chart - Zend OpCache + APCu + Static HTML Caching

Server Benchmark Results Chart – Zend OpCache + APCu + Static HTML Caching

CONCLUSION

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!

 

Comments


  1. comments

    4 Comments

    Add Your Comment
  2. 1. pajpaj

    Can you help how to set up this kind of caching? I am in a CloudLinux shared hosting. Thank you.

  3. 2. TehnoBlog (In reply to pajpaj)

    Hi pajpaj,

    Static (HTML) and APCu caching implementation is highly dependent on your application (CMS) that you use. Also, APCu needs core access to be installed and configured, so not sure if CloudLinux and your hosting supports it.

    1) OpCache is specific to PHP version and setting in php.ini configuration file, and it is ENABLED in all PHP 5.5+ versions by default, ask your hosting provider how to enable it, if it is not. You can use a simple php file to test it. Since you are on CloudLinux, you should have an option in your control panel to do it (may depend on your chosen plan/price, as well).

    2) If you use WordPress, static HTML caching is readily available through some plugins like WP Total Cache, Comet Cache and alike.

    3) For APCu caching in WordPress, you may try this plugin: wordpress.org/plugins/apcu/, but cannot tell you if it actually works. Again, server pre-conditions must exist in order for plugin to actually work.

    * * *

    For other CMS platforms, you will have to search/ask in specific places / support forums.

  4. 3. Wasseem

    Hi, nice layout analysis.
    Just one thing, in the results table, I think it should be “micro-seconds”, not seconds ;)

    cheers

  5. 4. TehnoBlog (In reply to Wasseem)

    Hi, thanks!
    No, the units are correct, for 800 cumulative requests, plus test was done on a slow budget server with a 10 Mbit/s network interface (check server specs above).

Post A Comment

I have read and consent to Privacy Policy and Terms and Conditions