Domain Mapping page cache flush, developer question

You aren t supposed to have page cache running in memcache in the first place its a waste of resources.

Disk Enhanced is the proper method for page caching.

It depends. Memory is much faster than SSD, therefor resource can be pushed much faster. It’s the proper way to cache when you have millions of visitors. The reason is much more elaborate, but that’s not why I opened this thread.

The class structure of the caching is pretty much the same for each module. Be it Xcache, Memcached, Disk, etc.

So if this problem (key storing) could be resolved, Domain Mapping and other extensions should work much better.

For example:
Give the cache storing ID’s per blog, so if you wish to “flush” a blog, you only have to pass the blog ID for a flush and everything bound to that blog ID will be flushed.

This way you can also track blogs cache, hits, etc. Name it.

Indeed, it is faster but the fundamental issue is when you are caching larger posts. For instance, if you have a video in the post the cache will pull the entire size of that post (video included) from memory now when we have a few users this is not a problem. However, when you have several concurrent users it can lead to resource problems especially when running it on multisite when there are several different web sites we would expect even more concurrent users. Furthermore, the performance increase is not that much better than disk enhanced.

But there does seem to be an issue with caching through multisite that I had not noticed until you pointed it out. I wonder if the effects are only due to domain mapping or if this is an issue with multisite in general.

I thought only the raw HTML is stored and from there, e.g. the video, CSS, JS, etc. is pulled from wherever it’s linked and stored.
In my case: MaxCDN.

Either way, I’ve only came by this issue with Domain Mapping.

The problem in short is that if you’ve mapped examplemapped.com, you can not flush it by URL unless you’re on exactly examplemapped.com and not on examplenotmapped.maindomain.com. Although the “key” is the same, it’s processed very deep down the line, together with encryption, compression, groups. Nothing of which is documented and it seems to be random. ??

I think a new function like w3tc_pgcache_flush_url($url) should be named and written as w3tc_pgcache_flush_blogid($blog_ID), what it does is self explanatory.

This just turned out to be merely a feature request rather than a bug report ??

Whoops, I see I typed that stuff out wrong lol let me clarify what I said. It is not caching the images however, page size does increase quite rapidly. For instance, let’s take one of my websites I am not done with.

https://thearcadecorner.com

Page Size: 1.72MB https://gtmetrix.com/reports/thearcadecorner.com/8uT0Rl0P

Cached Page Size: 68.82 KB. (those are exact numbers and my homepage is not done I am still developing and testing this site)

Now running it from Memcache might decrease the page load time a little bit more however. The problem is Memcache, APC, and other of the ram caching tools are more geared towards loading PHP and database requests. It’s also not smart to pull these resources of memory, for instance, a CSS file on my site could be 100kb but if there is more than 1 and javascript it starts to rack up on top of the normal page caching. Then when you have several users trying to access the site resources become scarce.

Normally the rule of thumb is to load minify and page from disk while database and object caching from APC or Memcache.

I do think it should support domain mapping though it would be amazing!

Total page size is that big indeed, but most of that size has been counted up because of static resources. Those are merely pulled from the server’s drive or CDN (unless you use minify, then it’s stored in the cache, be it memory or disk).

However, the part that’s actually stored with page caching is only the first thing: 11.2KB, now that isn’t big at all ??

Once again, it depends on many factors on how you should configure the caching. Sometimes it’s best to even disable page caching. Yet that could be a nice fallback tool if someone links you from Reddit for example.

That said, your rule of thumb is correct, but I doubt the page caching part.

Yup, for now I’ve installed Zend Opcache (300ms load time, without cache) with PHP 5.6 and pushed the caching down to 300 seconds (from 3600). This helps a lot and prevents confusion ??

It’s a temporarily solution yet I’m not afraid to say that I might keep it like this.

Either way, the feature requests stands:
“Please add a purge from blog ID function Frederick ?? Thanks!”

We have a site using Multisite with Domain Mapping and W3TC and we’ve been unable to clear the caches for individual sites in the network due to this issue. This has become a major problem for one of our clients. We may be forced to switch to a different cache plugin if this issue isn’t solved soon, but I would really rather not have to do that. W3TC is such an excellent cache plugin, I would hate to have to give it up over a plugin conflict that should be pretty easy for the developers to work out.

Has there been any progress on this issue? Any response from the developer?

Hi folks,

If you are in any way relying on the developer(s) of W3TC for a solution to any issue(s) you are having with the plugin, you are going to be disappointed and/or have angry clients.

My first, best suggestion is that you immediately – at the first sign of trouble – switch to another caching engine. Specifically, ZenCache: Fully operational; fully supported; streamlined code; and, the developers, unlike W3TC, do not knowingly, premeditatively, rob people with absolutely no intention of providing their customers with what they are entitled to in virtue of having handing over their hard-earned money (for those that opt for the paid-for version).

Be well,
AJ

I must note this question is related to the following plugin:
https://www.ads-software.com/plugins/w3tc-auto-pilot/

This makes cache handling a lot less painful, especially in MultiSite environments.

But the one thing that was bugging me is that there is no option to flush the cache per blog ID. This caused issues with the www. subdomain.

The solution I’ve used is:
However, I’ve lowered my caching times from a day to 180 seconds, which is pretty much on-demand cache after a first visit and keeps everything smooth and working when needed.

I also keep the plugin listed above up to date. There are still some issues with Widgets and Customizer to be worked out but once that 3 minute timer runs out it’s good again.

For now I think it’s best to wait out for PHP7 and install it once a stable release is out. It’ll massively improve your website’s speed, even without a caching plugin. It’s due expected at the end of this year.

But I digress and I think the previous reply should’ve been in their own respective topic within these forums.