Faster, Lighter, More Stable or “Little” about Wp-Super-Cache

    For some reason, as it seemed to me, the appearance of the next “omnipotent omnipotent reducing the load time and server load” WP-Super-Cache plug -in went quite quietly , but behind the hill only lazy people wrote about it and even managed to digg the plug-in page almost a thousand times . Therefore, I think it’s worthwhile to take a closer look and feel this miracle of programmer’s thought.

    So, what can this plugin do, why / for whom is it intended, and what is better than similar standard and not very caching tools?


    Introduction
    Most Wordpress users know the awesome WP-Cache 2 plugin . It caches the pages of the blog and gives them on demand without accessing the database. Despite this, you still have to load certain php code in order to serve already cached pages, so that they don’t talk about wp-cache (the progenitor of wp-cache2) on the page.

    WP Super Cache works on a different principle. After installation, html files are created and they are given to the browser without a single php call. How fast does your server render pictures? Almost as fast it will produce cached pages. If your site has to deal with a massive flow of visitors daily or periodically experience the Digg effect, then this plugin is for you.

    How does it work that?
    How do people usually act when preparing their site for a massive pilgrimage from digg? They manually save a copy of the page, which theoretically will generate the main traffic, and put it in the appropriate permalink folder. This method helps the server withstand heavy loads and does not "die", but its effectiveness directly depends on the ability to predict the flow of user interest in pages. WP-Cache itself, although useful, is not entirely adequate in certain situations, while WP Super Cache was created to recreate this process automatically.

    When an unauthorized visitor accesses a page or leaves no comments, the server gives him a static html page from the supercache subfolder , which is created incache WordPress folder. If you go to this folder (for example, ftp) , you will find an exact copy of your permalink structure in the form of folders and separate html files in each of them. To make sure that the page is created by the plugin, just look at its source code and you will find there the next line at the very end or for the compressed version.

    Logged-in users or those who leave a comment will be shown a cached page created using the standard WP Cache, where it will appear at the end.

    Chips / Differences from WP-Cache
    • Own hook system for finer caching settings (important only to developers).
    • Works great with both WordPress MU in VHOST and non-VHOST configurations. Files for each blog are cached independently of each other.
    • Standard WP-Cache files are divided into 2 parts. Meta files are now located in a separate folder, which increases the speed of accessing them and determining the need to update the cache.
    • Built-in patch for WP-Cache when working with secure posts.
    • Automatically disables gzip compression in WordPress instead of dying.
    • Improved work with Akismet and other anti-spam plugins - the cache will be updated only if the comment is 100% non-spam.
    • Button “lock down” (click) - prepares the site for a powerful influx of visitors. After switching on, it “snaps” static cache files and does not delete them after adding a new comment.
    • Automatically make changes to .htaccess (Remember to save your .htaccess before installing the plugin).
    • Requests with GET parameters are not cached.
    • Improved compatibility check wp-cache-config.php and advanced-cache.php if you used the old version.
    • Improved support for Microsoft Windows.
    • Works properly with cached pages on Red Hat / Cent or others that contain an entry for gzip in /etc/mime.types.
    • The Do Not Cache Following Addresses feature can now use regular expressions.


    Minuses
    • If you are logged in or left a comment, you will never see the super-cache page. You will always be given the good old WP-Cache. This is not so bad as most of your visitors never leave comments.
    • To work with static pages, Apache Mod Rewrite is used, so it is necessary that it be activated on the server.
    • Particularly dynamic parts of your site will not be updated as quickly as we would like. For example, the widget is the last comment.
    • Some hosting companies have problems working with compressed html files, incl. additional setup may be required.
    • Do not expect that cheap hosting will withstand a large surge in traffic, even if the pages are cached.
    • Remember that dynamic content like the one placed in the sidebar will only be updated when the cached page is refreshed. You can configure the time before the update, but cached files will be deleted only if you have a mixture of static and dynamic queries.
    • Some plugins, such as SK2, Bad Behavior and others, whose operation depends on the "freshness" of the data, may not work correctly, in any case, until these plugins are specially optimized to clear the cache at the right time.

    (c) Author of the Plugin

    This is all of course interesting and beautiful in words, but does it really work? I myself am not a master of load testing, so I will give the calculations of other people.
    Firstly, the author of the plugin sets an example for himself - after the announcement of Wp-Super-Cache on a digg, up to 4700 users jumped in, which is quite frank. And here are the graphs that turned out - the first outgoing / incoming traffic, the second - visits.
    wp super cache plugin traff graph
    wp super cache plugin visits graph
    The caching activation momentum (drop in outgoing traffic) is clearly visible, and it is also nice to see that the increase in visits does not affect the processor.

    Secondly, a certain Robertconducted performance measurements for 1000 requests. I tested it on a local network, on a server (P4 - 3Ghz, 2GB RAM) I installed a clean WordPress and made requests from another machine.

    Results:
    a) standard WordPress without a cache:
    - time for a test - 161 seconds;
    - requests per second - 6.21 / sec
    - time for 1 request - 161 ms
    - transfer speed - 31.07 Kbytes / sec

    b) WordPress + Super Cache:
    - time for test - 5.718750 sec;
    - requests per second - 174.86 / s
    - time for 1 request - 5.719 ms
    - transmission speed - 898.62 Kbytes / s

    c) WordPress + Super Cache + eAccelerator:
    - time for a test - 2.531250 sec;
    - requests per second - 395.06 / sec
    - time for 1 request - 2.531 ms
    - transmission speed - 2030.22 Kbytes / sec

    I think comments are superfluous.
    I turned on the plugin on this blog now , for a couple of minutes for the test I activated gzip compression and checked how browsers react. Everything is ok with Opera and FF, and IE6 as usual distinguished itself - he suggested saving the .html.gz page locally) In order not to frighten people, compression was disabled, but in general it will be necessary to figure out why IE reacted so.

    The installation plugin is quite simple, especially if you follow the recommendations in readme :-), but the setting for those who have not seen Wp-Cache2 before may seem incomprehensible. On the other hand, Wp-Super-Cache is a rather specific thing and not the fact that it will be in demand.

    The original of the article is “Faster, easier, more stable or“ a bit ”about Wp-Super-Cache” .

    Also popular now: