"Current Wasted" % always grows when object cache is enabled #23
Comments
|
Hi there, "Current Wasted" is related to OPcache. When enabling Object Cache, cached files in "wp-content/cache/docket-cache" will be cached by OPcache. It is more of a server-level OPcache setting. You need to fine-tune the OPcache settings. Thanks. |
I know about that, but issue is that it only grows when Docket Cache is enabled. It doesn't happen if it's not. So it's an issue related with the object cache. May be you could know about where to start to search. Also I'm not sure if it's the regular behavior of the plugin or it's not. |
Docket Cache writes its cache as a PHP file. When OPcache is enabled on your site, the cache files will be cached by OPcache to store them in memory. Therefore, there is no need to read the cache file because it is already in memory. This behaviour will improve the cache performance. If OPcache is not enabled on your site, Docket Cache object caching still works, but the performance is not as good as when has OPcache.
Docket Cache only uses OPcache to improve the cache performance. It can't control OPcache behaviour or settings, as that must be done at the server level. You may exclude Docket Cache cache files from being cached by OPcache using this opcache.blacklist_filename directive: Please refer to the link below to understand better:
Thanks. |
Thanks again for all the info. I already knew that. So, basically, AFAIK the issue is that this pluging is NOT compatible with OPCache because the inner working of this PHP mod is designed to work fine when there is not many changes into the PHP scripts. If PHP scripts begins to happen then the wasted memory grows and the cache must be restarted. This is totally the opposite of this WP plugin does because it's changing PHP scripts (into the cache folder) all the time so causing the wasted memory growing in OPCache. When I've blacklisted the cache folder being used by Docket Cache the issue stops and OPCache works flawlessly, as expected. So, if I'm not wrong in my thoughs (you can correct me if I am) you should advert all users of this plugin about blacklist all the cache folder as A MUST, to avoid any problems. Without adding that folder to the blacklist there are issues no matter what kind of WP installation is working on. Because AFAIK there is no way to have this plugin working having the cache folder cached by OPCache in memory, without having problems. |
|
Initially I though that this was a bug in your plugin. But now I've saw that it's not. It's how it's designed. And it's designed to do not work when OPCache stores the Docket Cache in memory. So this plugin is like if it works to accelerate object cache in WP, storing all data in memory, but it's not. Because you can't do this without issues. Never. There is no user of this plugin, having the standard configuration, with a better performance with this. So to my understanding, this is an alternative when you can't use Redis and need to lie to WP to make it believe that there is a object cache. But it really uses disk to store the objects data, not memory. Because to use memory you need to create a new OPCache from scratch with other way of manage the wasted memory. Am I right? |
Its works fine if you set the OPcache setting properly. OPcache will not cache if it reaches the limit, if you don't know yet please refer to this opcache settings Thanks. |
I already know about these and many other OPCache parameters. There is many parameters. And when I configured my server I already ensure that the max_accelerated_files and memory_consumption are large enough to have room for my needs. So these two params are correctly configured with my setup and they have not at 100% usage. But all of these are not the issue. I know about how to setup OPCache, it's not so difficult. As I've said before, when not using Docket Cache for object caching there is no issues; there are not wasted memory rising, there are not full usage of accelerated_files and the memory consumption is not at 100%. But what I am talking about and the issue I'm pointing here is the wasted memory usage when Docket Cache is installed. Then I can setup OPCache with new params (eg. larger max_accelerated_files and more memory_consumption) but I can't stop the wasted memory increasing slowly because there is no way to make this. At least to my knowledge. If you know any way to have the Docket Cache files in memory, that is, being cached by OPCache and NOT INCREASING the wasted memory with the time, please, say it or publish a guide to do so. The only way to have Docket Cache working in memory with OPCache is having an increasing amount of wasted memory and reseting the cache every day. But if I'm wrong and there is any method, it's very easy: just tell what is it. |
|
So what does it mean "Its works fine if you set the OPcache setting properly"? Does it mean that "works fine" is a 60% or more wasted memory? If it is, then you need, for example 500Mb for each 1 Gb of memory to store useless junk. It doesn't have any sense. If at least the wasted memory percentage stopped on 5% or 10% it could be acceptable, but it's not. It grows to 40%, then 50% and then 60% or more. |
|
Can you give a screenshot your Docket Cache "OPCACHE USAGE" tab page. |
Of course. Right now is working with blacklisted dirs to avoid the issue. Due to that there is a penality on the hit ratio.
|
|
and can you give the screenshot of Overview page |
|
If I remove the cache folder from the blacklist then the hit rate goes to 95% or 96% but then the wasted memory grows constantly. |
Here you have: |
|
Docket Cache cache file is only 16506 files. It is not too big and only 3MB in total file size. And you have excluded it from OPcache using opcache.blacklist_filename. And yet, OPcache usage is 530M out of 5382 files not included with Docket Cache cached files. You may need to increase the PHP limit; 512M is not enough to run Docket Cache with OPcache, I think. Or you can clear the cache every day or hour using this mu-plugins code https://gist.github.com/nawawi/b5a127989b38678f6260428bb1c13121 Or by using wp-cli Thanks. |
Yes I've excluded because if I do not do so, then the wasted memory grows. I've told you before. This is what this report is for. Because using Docket Cache plugin the wasted memory grows. About the current limit, displayed on these screen captures, this is because they were taken when object cache is being excluded with a blacklist. When I've tried without the blacklist it was on 1024Mb, so it was enough. I've also rised the OPCache size to 1024Gb in my tests, when not excluding the docket cache directory. I can increase the limits, use a double amount of memory for OPCache or PHP limits, but this doesn't solve the wasted memory issue. And this is what I need to solve. And, honestly, having to clear the cache every hour is a nonsense. It's against al the common sense of what a cache is designed for. |
|
After one day, values are as follows: |
|
And this is the OPCache tab:
|
|
This is WITHOUT using OPCache to cache the Docket Cache folder in memory, that is, having the docket-cache directory blacklisted to avoid the issue. If I remove the blacklisted directory then Current Wasted % grows and Wasted Memory the same. So it is a real and big issue, a big problem that AFAIK your plugin doesn't solve. So as it is, is really unusable for the purpposes of WordPress |
What is funny is that the fact that your code here make things even worse. Because that mu-plugin empties the object cache only, so after each execution there is more wasted memory in OPCache. Nice try anyway. |
|
That is a same code used in plugin when you hit flush object cache button. When deleting a cache file, OPcache will treat it as stale/outdated. It takes time for OPcache to reclaim it. Why you site run on localhost anyway? And that's all I can help with. |
Ok. As I see that you don't fully understand how WordPress works and the inners of object caching, I'll teach you a way to avoid the issue presented here. Because if we can't change the way in wich OPCache works, then we will assume that to act accordingly, not with fantasies about how it should work in other ideal world. That said let's examine the problem. The issue is being caused because the Docket Cache plugin CHANGES his files into the folder cache. And that is BAD. So if all of PHP scripts there are not the same with the time then it causes a growing memory wasted space. This doesn't happen if all PHP were always the same and there were no changes on them. So, thinking a bit about the issue I believe that a possible solution could be to create an smart mechanism on Docket Cache to analyze its own files to see were are frecuent changes and were there is not. This procedure involves a temporary folder, a intermediate folder, to store initially the PHP files and then, only if after a given amount of time (or may be it's not a matter of time but it's more a matter of a given number of queries) there is no changes, move them into the real cache path were OPCache could find them to store all into his memory. This folder should be created out of the scope of OPCache to avoid being cached or may be using a different file extension to avoid OPCache (something like "whatever.php_tmp" for example) This is, not to inmediately cache all into the object cache folder but wait a certain time to find the appropiate candidates to be stored there. And this way, as OPCache doesn't like the changes in PHP scripts (specially if validate_timestamps is true into the OPCache settings) the issue disappears. What do you think? I believe it's an easy and elegant solution, not very difficul to implement on your code and with a great benefit. The benefit is to not have unnecesarily wasted memory, filled with junk over the time. Creating this smart mechanism into Docket Cache plugin then the wasted space (caused by results that are not stable or constant) could be discarded by the garbage collector after some time without interferring with OPCache PHP module. |
|
Because aprioristically the Docket Cache plugin doesn't know what objects will be changed over the time, the propposed solution is to wait a bit. Just store them as non PHP script (to avoid OPCache caching) and compare it with future results of the same query to see if they are changing. If they are constant after some amount of time or after some N queries (may be that this could be defined by the user, into the Docket Cache settings tab) then (and ONLY then) the file is moved into the regular directory for caching objects. This procedure ensures that the OPCache will not be filled with unnecessary values that will change over the time. And this is what the OPCache is for, this is how it's implemented by design, because it doesn't work the same as Redis or Memcached or APCu |
|
I know that my solution, into the practice, involves a non inmediate benefit of using Docket Cache but after some time only. Think about it as a warming process. First the plugin stores the data as temporary just to compare and analize future queries. And then, when the system are being working for a while, when Docket Cache mechanism knows what objects can be stored without breaking or interferring with OPCache methods, is when it stores them as usual, as it does right now. |
|
I noticed that your plugin has DOCKET_CACHE_IGNORED_GROUPS, DOCKET_CACHE_IGNORED_KEYS and DOCKET_CACHE_IGNORED_GROUPKEY constants wich potentially could be useful to avoid issues like the growing wasted memory in OPCache. But the problem is to know what keys or groups should be excluded because this varies for each WordPress installation and depending on the plugins used. But it could be very useful to have some info reported into the Docket Cache tabs about what is being stored. If there are groups or keys causing changes, because the values are changing frecuently with the time it should be reported to let the user knows about it and to act excluding groups or keys by using the constants defined into wp-config.php I believe that this is also causing problems. So may be both solutions proposed here should be taken into acount to develop a future Docket Cache update. Both procedures doesn't exclude among them so I believe that you can use them at the same time (or may be only one of them is enough if it's well implemented and tested) |
The site doesn't run in localhost. It's an error with Docket Cache plugin that it's not indentifying the Cloudflare IP correclty. So it's not working well, the data exposed is wrong. You should fix that a bit. |
|
@fidoboy youre absolutely correct about everything. This is not an issue with how opcache, docket or wp are configured. It is inherent to OPCache itself. It is concerning that the dev of this plugin doesnt seem to understand how OPCache or WP Object cache actually works. I was initially excited to find Docket, but then quickly came to realize that it would suffer from everything you've explained above. Worse, I discovered it from reading this excellent re-posted article in the Docket Docs! https://docs.docketcache.com/resources/opcache-extension Docket is not appropriate for this use case, unless you have a large amount of RAM, a site that isn't very active or dynamic, and are also able to run a cron job every night to restart OPCache. Better to stick with Redis or SQLite Object Cache (which has shown in their benchmarks that sqlite is faster than docket anyway) |
You'll probably never understand how happy you made me by leaving your comment here.. Thanks a lot for it. Unfortunately, the developer of this project has also readed and understood my explanations and as consecuence there is no answer. I think that it's a real pitty because in our speciallity of knowledge should be a great motivation to the happiness to find and solve the errors caused by bad implementations, a bad aproach to solve a problem or many mistakes that unfortunately are many times very hard to find. I honestly think that with a little of effort and some motivation, this plugin could be much better and serve in some way to the purppose of make a Wordpress installation a little faster. But this is now in the hands of his creator. Thanks again for leaving here your impressions. Kind regards, |
|
Im glad that my comment was helpful to you - I could see and sense your exasperation through the thread, so I felt compelled to let you know that your assessment was accurate. I dont really see how this plugin could ever really be made production-ready - it seems to be well-made and well-documented, but OPCache simply isn't an appropriate technology for this use case. SQLite seems to be the way forward - it could hardly be a more mature and ubiquitous tool, should work on any host, doesn't require much/any RAM, is ultra-fast, etc... It is likely even more appropriate than Redis on most sites. |
I've noticed that the percentage is growing slowly but can't understand why. It doesn't happens when the object cache is disabled. I've tried disabling preloading menus, translations, etc. but can't get it working as expected.
What alse can I try?
The text was updated successfully, but these errors were encountered: