Keith
Forum Replies Created
-
Forum: Plugins
In reply to: [Docket Cache - Object Cache Accelerator] MultiNetwork compatibility?It seems like there is little bit of confusion in folder structure. For each sub-network, should I go with /docket-cache/network-x or /docket-cache-x/network-x?
Forum: Plugins
In reply to: [Docket Cache - Object Cache Accelerator] MultiNetwork compatibility?Thx for sharing the rc version. @nawawijamili
I think I pretty much followed what you mentioned, but it does not seem sub-network’s create ‘Object Cache’ that in overview, I see Object Cache ‘Not Available’.
In ./cache/docket-cache-x/network-x folder, I can see that there are some files, but again, not sure if Object cache is really working. Zend OPcache seems working fine that in overview I can see ‘123M emory of 3642 files’.
Just to confirm my steps,
- added ‘define(‘DOCKET_CACHE_PATH_NETWORK_x’, ‘/var/www/superadmin.giai.org/wp-content/cache/docket-cache-x’);’ to wp-config.php
- in ./wp-content/cache folder, I do have /docket-cache-x
- I have activated docket cache plugin in sub-network’s admin network
- mounted the folder to ram disk
- This reply was modified 2 years, 6 months ago by Keith.
Forum: Plugins
In reply to: [Docket Cache - Object Cache Accelerator] MultiNetwork compatibility?Just so you know, the cache path and config path are set differently for each sub-network. Just wonder why then it does not create cache files for each sub-network. Either I missed something, or it does not work?
Forum: Plugins
In reply to: [Redis Object Cache] Multiple groups for subsites@julieadrienne Thx for the quick update. What about your Pro version? This is not the most popular option, I guess, but it is needed to create several files of Redis cache, if one server runs a lot of websites all together.
The above configuration option’s ‘global’ feature looks somewhat related.
Forum: Fixing WordPress
In reply to: REST API encountered an errorFor first error, I have below error msg across multisite.
Page cache enhances the speed and performance of your site by saving and serving static pages instead of calling for a page every time a user visits. Page cache is detected by looking for an active page cache plugin as well as making three requests to the homepage and looking for one or more of the following HTTP client caching response headers: cache-control, expires, age, last-modified, etag, x-cache-enabled, x-cache-disabled, x-srcache-store-status, x-srcache-fetch-status. Median server response time was 1,096 milliseconds. It should be less than the recommended 600 milliseconds threshold. There were 3 client caching response headers detected: cache-control, expires, last-modified.no it got worse. I rolled back to PHP 8.2. Not sure if it is PHP 8.3’s incompatibility with one of the plugins, Nginx, Redis, but on my test server w/o Redis, I can have little bit of performance upgrade by PHP upgrade.
I have tried again today, but ended up with the same situation. Redis’s metric did not look as before. There were jumps in every a min, like a squeezed sine/cosine graph.
Forum: Fixing WordPress
In reply to: Extremely slow in loading after updating to PHP8.3@t-p thx for the quick feedback, though I do not believe it is anything to do with deprecated warning msgs.
I narrowed down issues.. WP’s REST API didn’t work during the trouble. I still do not have the solution, so I went back to PHP8.2 at the moment. Glad that I did not purge the earlier version.
Don’t know how dual version works in detail, but after switching back to 8.2, I have much faster performance. I almost feel like I go to freshly installed WP page.
I turned off Jetpack because of above issue.
I practically followed all your instructions from here, which means essentially there is no page level caching working on my server, except Nginx’s default FastCGI caching. I also disabled WP-Rocket – Nginx optional add-on, which uses WP Rocket’s stored html file directly served by Nginx
There are issues emerging, however.
- WebP images are no longer served, from time to time (guess it could be EWWW IO’s issue. not sure)
- When fall back occurs, it becomes way much slower. I believe it is because the system has to recreate html to for service, and shouldn’t be so again.
- Logged-in users are not served by cache at all, at least I feel so
Up to above, it is still amazing. I can almost fully enjoy Cloudflare’s caching w/o any additional cost, unless I have huge traffic.
But still, without WP Rocket’s user cache, #3 is going to be a problem for logged-in users. For my case, they are paid members, and I feel that I am obliged to offer extra service, though what I give them is much slower performance.
Having tested the recommended setting for about 12 hours by now, I can see that cache hit ratio went down from 95+% to 50~60%.
Accordingly, TTBF emerged as a concerning issue. The page speed performance score went down from 97~99 to 90~92 for each post page. Still an outstanding score, and it indeed is more cache hit ratio than vanilla cloudflare set-up. However, unless I did anything wrong, it is not as effective as the APO option, at least for my site.
Cached contents usually take a day or two for full adoption, so I will give another 12 hours for the performance check, but if the past 12 hours is the standard, I will say $5/month for APO was worth the money.
Should be nothing to do with your team’s plugin, but I wonder why APO is not compatible with Cache Everything rule. Thought APO, by its name, should optimze caching ‘automatically’ for wordpress.
So if I understand it right, I had admin bar visible to non-logged in users, because I had both APO and SCfC? If I choose only one option, then you believe the admin bar issue will be gone? And, for testing two options, guess combinations are
- Cloudflare WP plugin + APO enabled
- Super Cache for Cloudflare + Cache Everything rule
You guys believe the 2nd option is superior to, or at least in par with the paid 1st option?
Not sure which one works better, but as long as I can remove conflicting issues with membership, I am fine. Thought APO’s $5 per month option works better than free version, but this is kinda surprising information.
OK let me get this straight. I have to
- disable cloudflare’s official WP plugin,
- disable APO,
- enable cache everything,
- enable Super Cache for Cloudflare
Is this correct? I am sure you recommend the right setting, but then how does SCfC w/ cache everything make any difference to cloudflare native plugin w/APO?
My domain is example.com, and the subdomain in question is subdomain.example.com
You can find the screenshot of the page rules page is from here.
As you can see, all three subdomains have cache everything rules, but I have turned off them.