Faster-easier-more stable or “a little” about Wp-Super-Cache
For some reason, it seemed to me, the appearance of another “omnipotent omnipotent reducing load time and server load” of the WP-Super-Cache plug -in went quite quietly, and after all, only lazy people didn’t write about the bump and even managed to Digg the plugin page almost a thousand times . Therefore, I think it is worthwhile to look closely and touch this miracle of programming thought.
So, what can this plugin do, what for / who is it intended for and better than similar standard and not so caching tools?
Introduction
Most Wordpress users know the wonderful WP-Cache 2 plugin. It caches blog pages and gives them on request without accessing the database. Despite this, you still have to load a certain php-code in order to maintain the already cached pages, so that they don’t talk about wp-cache (the progenitor of wp-cache2)
WP Super Cache works on a different principle. After installation, html files are created, and they are given to the browser without a single call to php. How fast is your server giving pictures? Almost as quickly, it will produce cached pages. If your site has to deal with a massive stream of visitors every day or periodically experience the Digg effect, then this plugin is for you.
How does it work then?
How do people usually act when preparing their site for a mass pilgrimage with digg? They manually save a copy of the page, which theoretically will generate the main traffic, and place it in the folder corresponding permalink. This method helps the server withstand heavy loads and not “die”, but its effectiveness directly depends on the ability to predict the flow of user interest to the pages. Although WP-Cache itself is useful, but in certain situations it is not quite adequate, while WP Super Cache was created to recreate this process automatically.
')
When a non-logged visitor accesses the page or he leaves no comments, the server gives him a static html page from the supercache subfolder, which is created in the cache folder of WordPress. If you enter this folder (for example, via FTP) , you will find an exact copy of your permalink structure as 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 the next line there at the very end or for a 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
Minuses
(c) Plugin Author
This is all certainly 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 itself as an example - after the announcement of Wp-Super-Cache in the digge, visits have jumped up to 4,700 users, which, frankly, is not a little. And what charts have turned out - the first outgoing / incoming traffic, the second - visits.
The moment of activation caching is clearly visible (drop in outgoing traffic), and it is also pleasant to observe that the increase in visits does not affect the processor in any way.
Secondly, a certain Robert spent 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 cache:
- time per test - 161 seconds;
- requests per second - 6.21 / s
- time for 1 request - 161 ms
- transmission speed - 31.07 Kbytes / sec
b) WordPress + Super Cache:
- time per test - 5.718750 seconds;
- requests per second - 174.86 / s
- time for 1 request - 5.719 ms
- transmission speed - 898.62 Kbytes / sec
c) WordPress + Super Cache + eAccelerator:
- time per test - 2.531250 sec;
- requests per second - 395.06 / s
- 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 the browsers react. With Opera and FF everything is OK, and IE6 as usual distinguished itself - offered to save the page locally .html.gz) In order not to frighten people, compression was turned off, but in general it would be necessary to figure out why IE responded so.
The plugin in the installation is quite simple, especially if you follow the recommendations in the 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 a fact that it will be in demand.
The original of the article "Faster-easier-more stable or" a little "about Wp-Super-Cache . "
So, what can this plugin do, what for / who is it intended for and better than similar standard and not so caching tools?
Introduction
Most Wordpress users know the wonderful WP-Cache 2 plugin. It caches blog pages and gives them on request without accessing the database. Despite this, you still have to load a certain php-code in order to maintain the already cached pages, so that they don’t talk about wp-cache (the progenitor of wp-cache2)
WP Super Cache works on a different principle. After installation, html files are created, and they are given to the browser without a single call to php. How fast is your server giving pictures? Almost as quickly, it will produce cached pages. If your site has to deal with a massive stream of visitors every day or periodically experience the Digg effect, then this plugin is for you.
How does it work then?
How do people usually act when preparing their site for a mass pilgrimage with digg? They manually save a copy of the page, which theoretically will generate the main traffic, and place it in the folder corresponding permalink. This method helps the server withstand heavy loads and not “die”, but its effectiveness directly depends on the ability to predict the flow of user interest to the pages. Although WP-Cache itself is useful, but in certain situations it is not quite adequate, while WP Super Cache was created to recreate this process automatically.
')
When a non-logged visitor accesses the page or he leaves no comments, the server gives him a static html page from the supercache subfolder, which is created in the cache folder of WordPress. If you enter this folder (for example, via FTP) , you will find an exact copy of your permalink structure as 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 the next line there at the very end or for a 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 system of hooks, for more fine-tuning caching (important only for developers).
- Works great with WordPress MU in VHOST and non-VHOST configurations. Each blog files 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 access to them and determine the need to update the cache.
- Built-in patch for WP-Cache when working with protected posts.
- Automatically disables gzip compression in WordPress instead of “die.”
- Improved work with Akismet and other anti-spam plugins - the cache will be updated only if the comment is 100% not spam.
- Button “lock down” (latch) - prepares the site for a powerful influx of visitors. After switching on, it “latches” static cache files and does not delete them after adding a new comment.
- Automatic changes to .htaccess (Do not forget to save your .htaccess before installing the plugin).
- Queries with GET parameters are not cached.
- Improved compatibility check wp-cache-config.php and advanced-cache.php, if you used the old version.
- Improved Microsoft Windows support.
- It works correctly with cached pages on Red Hat / Cent OS or others that contain an entry for gzip in /etc/mime.types.
- The function "Do not cache the following addresses" can now use regular expressions.
Minuses
- If you are logged in or have left a comment, you will never see the super-cache page. You will always be issued the good old WP-Cache. This is not so bad as most of your visitors never leave comments.
- To work with static pages, Mod Rewrite Apache 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 comments.
- Some hosting companies have problems working with compressed html-files, t.ch. may require additional configuration.
- Do not expect cheap hosting to withstand a large surge of traffic, even if the pages are cached.
- Remember that dynamic content, like the one that is placed on the sidebar, will only be updated when the cached page is updated. The time to update can be customized, but cached files will only be deleted if you have a mixture of static and dynamic queries.
- Some plugins, such as SK2, Bad Behavior and others, whose work depends on the "freshness" of the data, may not work quite correctly, at least until these plugins are specially optimized for clearing the cache at the right moment.
(c) Plugin Author
This is all certainly 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 itself as an example - after the announcement of Wp-Super-Cache in the digge, visits have jumped up to 4,700 users, which, frankly, is not a little. And what charts have turned out - the first outgoing / incoming traffic, the second - visits.
The moment of activation caching is clearly visible (drop in outgoing traffic), and it is also pleasant to observe that the increase in visits does not affect the processor in any way.
Secondly, a certain Robert spent 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 cache:
- time per test - 161 seconds;
- requests per second - 6.21 / s
- time for 1 request - 161 ms
- transmission speed - 31.07 Kbytes / sec
b) WordPress + Super Cache:
- time per test - 5.718750 seconds;
- requests per second - 174.86 / s
- time for 1 request - 5.719 ms
- transmission speed - 898.62 Kbytes / sec
c) WordPress + Super Cache + eAccelerator:
- time per test - 2.531250 sec;
- requests per second - 395.06 / s
- 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 the browsers react. With Opera and FF everything is OK, and IE6 as usual distinguished itself - offered to save the page locally .html.gz) In order not to frighten people, compression was turned off, but in general it would be necessary to figure out why IE responded so.
The plugin in the installation is quite simple, especially if you follow the recommendations in the 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 a fact that it will be in demand.
The original of the article "Faster-easier-more stable or" a little "about Wp-Super-Cache . "
Source: https://habr.com/ru/post/16821/
All Articles