[Resolved] Caching on post relationships

[Author]

Posts

[ashiA]

Hi,

This is a follow up on my previous support request -- https://toolset.com/forums/topic/caching-on-post-relationships/ (some background information on the project is available in the thread).

I was away for some time, and the issue got automatically marked resolved, which is why I am creating a new issue. If you would prefer to continue the previous issue, I have also raised the same query there.

I had a few additional clarifications that I required:

(1) ENTITY / CONTENT CACHING
If I understand correctly, for many-to-many related posts, the views displaying related post information will not get cached at the views level. A 3rd party caching plugin, is likely to cache the entire HTML of the post (not the relationship per se), which will get invalidated whenever the cache in that plugin gets cleared.

I am trying to shift to toolset from Drupal. Drupal has some advanced caching possible, including (a) entity caching -- caching for example this relationship (b) content caching -- allowing the use of caching tags that keep the content cached until some content is not changed (and if content is changed, it is smart to only clear caches of affected content).

I wanted to check if there is any similar functionality that is available on WordPress (even if you can direct me to 3rd party plugins that would be very helpful). To explain the reason, I may create a set of author bios that may not change for many years. I would ideally like to be able to

Entity level caching: which allows me to cache the data I am pulling via the view relationship. This would allow me to set a much higher TTL, since I know this content will change very rarely
Content caching: which is the ideal. Here the content will remain cached until it is not changed -- and to clarify, only affected content caches get cleared

(2) CACHING DOCUMENTATION
Caching is a very important matter when it comes to dynamic sites with complex post relationships. I think it would help all your users a lot, if you could come up with some recommendations on best practices on how to deal with more complex situations when it comes to toolset and 3rd party cache systems (similar to how you have created specific documentation on how to work with recommended themes). Most documentation on caching is pretty old and related to a 1.1 views release.

If there is something like this available, would much appreciate.

(3) ARE POST REFERENCES MORE PERFORMANT THAN RELATIONSHIPS
I understand post references only work for one-to-one, but some aspects of the site architecture could allow for this. Since I seem to be able to display data from a reference (as compared to related) post without having to go through a view, I was wondering if these are more scalable and a better architecture to use versus relationships.

(4) POST RELATIONSHIPS VS TAXONOMY
Is there a difference in performance and scalability of queries, if I use taxonomy instead of relationships. I was keen on using posts to link together certain content (primarily due to the ability to 'favorite' post, which is not available on taxonomies), but if there is a material performance difference, I can possibly let go of some of this functionality.

Broadly trying to understand, from a performance and scalability perspective, am I better of replacing as many one-to-many and many-to-many post relationships, with post references and taxonomies instead.

[Christian Cox]

If I understand correctly, for many-to-many related posts, the views displaying related post information will not get cached at the views level.
In some cases yes, in other cases no. The specific cases mentioned here will bypass Views caching: https://toolset.com/documentation/user-guides/front-page-filters/how-to-use-views-parametric-search-on-large-sites/
On the other hand, a View querying related M2M posts related to a known, predefined post ID may be cached at the View level. When you change that from a known, predefined post ID to something dynamic, like the current post, or a View ID set by a shortcode attribute, then caching is not used.

(1) ENTITY / CONTENT CACHING: A 3rd party caching plugin, is likely to cache the entire HTML of the post (not the relationship per se), which will get invalidated whenever the cache in that plugin gets cleared.
Good 3rd-party caching tools are smart enough to allow you to dump the cache for specific pages of the site, so there is more control than just one big cache.

(1) ENTITY / CONTENT CACHING: I wanted to check if there is any similar functionality that is available on WordPress
There's nothing like this built-in to Toolset, and I'm not aware of any 3rd-party plugin integration that provides this type of feature. However, with the caching rules from the Views caching document in mind, you might be able to create cacheable Views that avoid the situations that might invalidate caching. For example, instead of one View that queries posts related to the current post, you can create multiple Views that query posts related to a specific post.

(2) CACHING DOCUMENTATION
This is a great recommendation, and I think the best way to see this information gathered and added to the site is to submit your request via our feature request page. It's geared towards the software suite, but a request for the site will also get seen by key decision makers:
https://toolset.com/home/contact-us/suggest-a-new-feature-for-toolset/

(3) ARE POST REFERENCES MORE PERFORMANT THAN RELATIONSHIPS
Post references are, essentially, one-to-one post relationships. They will usually be more performant than one-to-many relationship queries or many-to-many relationship queries with or without intermediary post types, but not necessarily more performant than other one-to-one relationship queries.

(4) POST RELATIONSHIPS VS TAXONOMY
Is there a difference in performance and scalability of queries, if I use taxonomy instead of relationships.
A complex relationship query is going to be less performant than a simple taxonomy query. However, there are features in post relationships that you cannot achieve with taxonomies. For example, you cannot add a custom field to the relationship between a post and a taxonomy. At the same time, queries based on those intermediary custom field values are less performant than taxonomy queries. Again, it's best for you to create dummy content and see how it will perform in specific scenarios.

[ashiA]

Thanks a lot for your detailed response, it is helping me get a much better idea on how to structure out the site.

I just had a couple of quick follow-ups ---
(a) would a taxonomy query still be more performant than a simple (not complex) relationship query OR if complexity levels are similar would both be similar in terms of performance?
(b) is there any way to specify the TTL on view caching.
(c) If there is an exposed filter / parametric search, I know this does not get cached under standard view caching. I just wanted to check if you are aware of whether it is possible to have parametric searches cached using popular 3rd party caching plug-ins / Varnish. The reason this is important is that there is one view which I am using repeatedly through the site, that has a single parametric search with only 5 options. Since my content is unlikely to change often, it would really be helpful if for this to get cached even for the parametric options.

[Shane]

Hi Ashi,

Christian is currently not available today but will be back tomorrow to continue with you.

Thanks,
Shane

[Christian Cox]

(a) would a taxonomy query still be more performant than a simple (not complex) relationship query OR if complexity levels are similar would both be similar in terms of performance?
A hypothetical generalization like this isn't detailed enough for me to provide a solid answer, unfortunately. Again, you should set up a test environment to perform your own evaluations in real-world scenarios. Install a plugin like Query Monitor to monitor performance, and use FakerPress or another plugin to add lots of sample data. Then compare the results of your relationship queries vs taxonomy queries as the number of posts grows. Then you will have measurable metrics, which are more reliable than hypothetical what-ifs.

(b) is there any way to specify the TTL on view caching.
No, there is no way to customize the TTL on View caching. The settings are built-in to the plugin, and not configurable.

I just wanted to check if you are aware of whether it is possible to have parametric searches cached using popular 3rd party caching plug-ins / Varnish.
I'm not sure, that's a bit outside the scope of what I'm trained to provide here. You would need to check with those services/providers to see exactly how they handle caching of parameter-based queries.

[ashiA]

My issue is resolved now. Thank you!