websavers
Forum Replies Created
-
Emailed logs just now! We can continue via email if you wish; whatever is easier for you.
That’s a good find!
I wish I could say it resolved the problem, but after completing the suggested steps using devfix6, the cache dir grew to >1GB in under 5 minutes still 🙁
And the same issues are present with CPU usage spiking on PHP processing and searches taking a very long time.
Should I try the constant values in wp-config from your prior post? Or will those not work with devfix6?
Hey @nawawijamili
Tried it out. It somehow seems to be even slower at the WOOF product searches.
I do see it generating the hashed path for cache files.
Interestingly the default setting for “Cache Disk Limit” is set (500M), yet the docket-cache folder size according to
duhas grown to 2.5G in just 10 minutes.The correct error does indeed appear now if timeout is hit when flushing 🙂
“Object cache could not be flushed. Maximum execution time of 30 seconds exceeded.”
But I’m afraid that also means flushing the cache hasn’t been improved by this either, at least by the time the cache grows to be 2.5GB. I’m wondering if it’s duplicating files rather than replacing them when content needs updating.
On the upside the hash path method means I was able to run the standard
rm -rf docket-cache/*to clear the folder contents.- This reply was modified 4 years, 3 months ago by websavers.
Hey @nawawijamili
The devfix file will stop the flushing process if reach maximum execution time. It is my bad decision, should leave it to PHP to throw the error message.
Ahh, so that explains the slight improvement with that version in that at least when it hits the timeout it stops processing.
Thanks for the suggestion, really appreciate it.
No prob! I hope it actually helps. It certainly seems like it could be a solution to the issue, but I don’t know that with certainty.
It may take a long hour to revamp and test it again with opcache and everything. If possible, I may require your/team help to test it on your environment once it complete.
Understandable! Happy to test whenever you have it ready 🙂
- This reply was modified 4 years, 3 months ago by websavers.
I deleted the contents of the folder manually:
find . -type f -deleteFlushed the cache from Docket’s end, re-enabled the object cache and as far as I can tell the issue is resolved. But I suspect if it continues to generate large numbers of files, the problem will return.
Edit: After about 15 minutes it was up to 75k files and super slow searches again.
I think this identifies a couple possible improvements:
1. FLUSH CACHE RESPONSE / ERRORS:
Ensure the response from flushing the cache is accurate – if it doesn’t actually flush the cache, it should indicate when it was unsuccessful. When unsuccessful it might also be beneficial to indicate to the end user that they need to clear it manually.
2. ALPHABETIC HASH DIRECTORY SYSTEM?
It sounds to me like Docket could minimize the problems created by this scenario by using an alphabetic hash directory system for storing its files. This way even if there’s a problem, flushing the cache should work more consistently. This *might* also improve cache file access times when there’s a large number of cache files. At bare minimum, even if the number of cache files is larger than it should be, due to some other conflict, this would be a great way to mitigate the effects.
Cheers,
Jordan
Also interesting: it says “Object cache was flushed.” after the 30 seconds, but the number of files in wp-content/cache/docket-cache is now higher… I’m used to cache flushes clearing the contents of the cache folder, is that not how this works with Docket?
I also can’t erase that folder manually as there’s too many files in the argument list to run rm -rf on it.
Perhaps the cache flush is simply reaching the PHP 30s timeout, but for some reason Docket says it was a successful cache flush, when it actually didn’t flush anything?
Hey @nawawijamili
Apologies for the lack of response to the last message – I’ve been meaning to get back to you!
It seems improved with the latest devfix, but searches are still faster when object caching is disabled entirely.
I do think you’re probably right about it being connected to cache flushes. Even with the object cache drop-in disabled, if I flush the object cache it takes a good 30 seconds and CPU usage of PHP processes spike. Perhaps even weirder, if I flush it again about 15 seconds later (with the object cache having never been enabled in between), it does the same thing – 30 seconds processing, and significant CPU usage.
The server powering this has strictly SSDs and IO performance is pretty solid overall. When I flush the object cache, iotop shows practically no IO activity. Yet htop indicates it’s at least 50% kernel time.
wp-content/cache/docket-cache contains 97,643 entries and running ls on it takes some time. I’m wondering if the issue here is the same issue we run into when you don’t tell WP to organize uploads by date: simply too many files in one folder causing access performance issues — that would explain the kernel processing time when I flush the cache. I’ve seen other file stores like this split the files alphabetically (alpha hash?) into folders like aa, ab, ac, ad, … ba, bb, bc, … fa, fb, fc.
Hey @nawawijamili
Tried out the devfix version. Immediately after reactivating the Object Cache Drop In, load went from 0.5-0.6 up to 2.5 and numerous PHP processes were stuck at 100% CPU.
Disabled it again and processing went back to normal (after a PHP-FPM restart to clear the long-running processes).
You mentioned these options:
– Admin Object Cache Preloading: was enabled
– Advanced Post Caching: was enabled
– Object Cache Precaching: was disabledI disabled the first two as well (so all of those are disabled), then enabled the object cache drop in again and the issue returned.
I dunno what it is about the WooCommerce Products Filtering plugin, but it’s definitely got some kind of incompatibility with object caching. Is there a way to determine how to exclude its searches, or something like that? It’d be nice if they could play nice together without having to disable options globally.
Submit as a support ticket 🙂
Thank you @champsupertramp !
I am not a huge fan of the need to add this data to postmeta for every post when it applies to every single one of them. It just seems wasteful to me, though I get why this is a good option for some.
Instead of this method (and because I found the original devs of this site already had a custom page template for the post type) I modified the page template and put my display conditionals based on user role in there.
- This reply was modified 4 years, 9 months ago by websavers.
Forum: Fixing WordPress
In reply to: CORS (Cross-Origin Resource Sharing@glaukabazi that is a great question. And from what I can tell, yes this should be fixed by WordPress. In theory, my understanding of this flaw is that a malicious user could set up a MITM attack by:
1. Setting up their own web server that proxies all wp-json queries (or REST API in general)
2. Configuring that server to include its own domain as the Origin value in the request
3. Because of (2), the server hosting WordPress would then allow that malicious origin to retrieve and show the data on the malicious domainNow, normally this isn’t a big deal because the wp-json data showing is public data anyway. However if the mailcious user tricks an already authenticated user (authenticated with WordPress through normal mechanisms on the real/live WordPress domain) to then access their mailcious URL, the malicious server could then capture json data which is private and expected to be only available to the logged in user.
My guess would be that the solution here is to, at bare minimum, not have this header present:
header( 'Access-Control-Allow-Credentials: true' );OR perhaps better yet to have a setting in WordPress where you configure the allowed origin domains and unless it’s explicitly set by the site owner, these headers are not added at all. When it is set, it only applies to the configured origin and not an arbitrarily set origin from the request data.
—
If you’re setting the CORS headers yourself in the web server config, you can use this in your functions.php or the Snippets plugin to disable these headers:
//Remove CORS headers for REST API that allow arbitrary origins add_action( 'rest_api_init', function($var){ remove_filter( 'rest_pre_serve_request', 'rest_send_cors_headers' ); }, 15, 1 );@hchouhan Thank you!
Hey @hchouhan
Thank you, that’s exactly what I needed, particularly for the member types profile fields.
Just to confirm, you said only email address is sent by default… wouldn’t/shouldn’t it also include the person’s name since it is pulled from the WordPress user fields rather than BuddyPress xprofile fields?
Or are you saying I *do* need to connect the person’s name using that custom code because I’m using BuddyPress?
Cheers!
Forum: Plugins
In reply to: [Search by SKU for Woocommerce] Search by SKU not working WC 3.4.6Hey there,
Front-end searching could be any number of issues, but if you’re experiencing SKU search problems *also* in the WordPress admin, check this WooCommerce Issue out for details on how to fix this up.
-websavers.ca
Forum: Plugins
In reply to: [WooCommerce] Not variable product showing as out of stock@vhfilgueiras You’re right – it *shouldn’t* be an issue. It is, however, the issue we’re having. In my testing, removing or cancelling these orders has released the stock and the cart functions properly again.
@fernashes – pending payment orders are holding stock despite hold stock being disabled.