Skip Navigation

[Resolved] Caching on post relationships

This thread is resolved. Here is a description of the problem and solution.

This support ticket is created 5 years, 10 months ago. There's a good chance that you are reading advice that it now obsolete.

This is the technical support forum for Toolset - a suite of plugins for developing WordPress sites without writing PHP.

Everyone can read this forum, but only Toolset clients can post in it. Toolset support works 6 days per week, 19 hours per day.

Sun Mon Tue Wed Thu Fri Sat
8:00 – 12:00 8:00 – 12:00 8:00 – 12:00 8:00 – 12:00 8:00 – 12:00 - -
13:00 – 17:00 13:00 – 17:00 13:00 – 17:00 13:00 – 17:00 13:00 – 17:00 - -

Supporter timezone: America/New_York (GMT-04:00)

This topic contains 4 replies, has 2 voices.

Last updated by ashiA 5 years, 10 months ago.

Assisted by: Christian Cox.

Author
Posts
#1179252

Hi,

I wanted to understand how caching works in the case of post relationships. As an example, let us take an example of a book review, where I also want some details of the author's biography. There would be 2 options

(a) Write the book review, and the author biography as a single post .. Requiring me to manually duplicate the author bio in all other books he has written on the site... Caching here is obvious

(b) Create an 'author' post type, and create a relationship between the book review and the author.. the questions here are:
(1) Does this get cached the same way as a normal post? In which case, how does the author bio on the book review post get updated, if I update the author bio is updated
(2) It seems like there are a lot of join operations and DB queries in creating the author bio relationship, as compared to a normal post. Can this become an issue on a larger site.

#1179299

Does this get cached the same way as a normal post?
Can you explain what type of caching you are referring to? There are many types of caching and many levels of caching. If you're talking about Views caching, you can refer to our documentation here:
https://toolset.com/documentation/user-guides/front-page-filters/how-to-use-views-parametric-search-on-large-sites/

If you're asking how relationships are stored in the database, Toolset has some special database tables that hold post relationship information. These are not identical to the post table or the postmeta table.

It seems like there are a lot of join operations and DB queries in creating the author bio relationship, as compared to a normal post. Can this become an issue on a larger site.
Toolset's post relationships API does make more queries than a normal post, because the post relationship information is stored in separate tables specifically designed for Toolset. Simply creating the relationship or linking two posts in the relationship probably isn't going to be a problem. However, querying millions of posts and post relationships can be a challenge. It really depends on what you mean by "larger" and what you're trying to accomplish.

#1179852

Thanks for the prompt response.

Let me provide a brief description of the project, that I am working on. Once complete, the site is likely to have approximately 2000 book reviews, 1000 online course reviews, 2000 youtube video reviews, 300 - 400 author profiles and 2000+ blog post. What makes the architecture a bit more complex, is that the aim is to have all of these referencing each other -- for example, the author page would reference all content created by that author (could be books, online courses or youtube videos). Similarly, the blog post could have references to books, online courses, youtube videos and authors.

(a) Caching for post relationships
If I understand how relationships work correctly, to show the author bio on the book review page, this will need to be via a view that is created that recognises the author and book relationship, and displayed on the book review page via the content template for the book review.

The questions are as follows:
(1) Would such a view allow caching at the view level? If yes, will the book review update the author bio instantly on updating the author bio, or will there be a delay until the cache clears?
(2) If I use an external caching plugin (e.g. W3 total cache, WP super cache), will these cache such post relationships? Could this lead to delays?

(b) Defining the scale
The questions related to such an architecture would be
(1) Can these multiple relationships provide an issue with relation to scaling, or is this level of volumes / complexity manageable under toolset?
(2) If I consider the base version of a cloudways cloud hosting (1GB RAM, 1 Core, 1 TB bandwidth), is it possible to give a very rough ballpark estimate of how many concurrent users / monthly visitors can be supported?

Look forward to your responses on the same.

#1180168

(1) Would such a view allow caching at the view level? If yes, will the book review update the author bio instantly on updating the author bio, or will there be a delay until the cache clears?
The criteria for Views caching are explained in some detail here:
https://toolset.com/documentation/user-guides/front-page-filters/how-to-use-views-parametric-search-on-large-sites/
In your case, these criteria are important:
- The View shortcode has any attribute other than name, id or target_id....
- The View is nested or has a filter or an option that depends on the current page, current user, or current archive data.
- Things that also change the content or the status of posts, terms, or users will invalidate cache automatically.
This View of the author bio must either include a shortcode attribute which sets the context for the author bio, or it must be based on a relationship to the current page. In either case, Views caching is disabled.

(2) If I use an external caching plugin (e.g. W3 total cache, WP super cache), will these cache such post relationships? Could this lead to delays?
I can't really speak to how other specific 3rd-party systems work, but generally caching plugins produce static HTML versions of a site based on the output generated by the server. Then instead of querying posts again next time someone visits, the static HTML version of the page is served. Post Relationships aren't cached per se, but the overall HTML output generated by the page is cached. As far as leading to delays, it depends on the settings and configurations of those 3rd-party caching systems. The delay is completely controlled by their system and depends on when their cached version is programmatically invalidated.

(1) Can these multiple relationships provide an issue with relation to scaling, or is this level of volumes / complexity manageable under toolset?
Any relational system is going to experience slower query times as database size and query complexity grows. Simple queries like posts by a specific author are going to remain pretty fast. Complex queries like the 12 most recent video reviews by the author of a video review related to the current course review and having a specific custom field value are going to be slower. If you're asking me about your specific numbers and configurations, it's not really possible for me to predict accurately because it depends on too many variables. I suggest setting up a test site and using a plugin like FakerPress to generate some dummy content, then run some performance tests on both the front-end and back-end.

Managing post relationships between thousands of posts in multiple post types in the backend sounds...challenging. What if I want to relate 200 existing video reviews to a new course review? Each one of those connections must be made manually, either by selecting all 200 video reviews in the course review post, or by editing all 200 video reviews and selecting the course review post. While it is possible to use a CSV to import posts and maintain existing post relationships, there is no bulk-relate feature in wp-admin for existing posts.

On the other hand, a taxonomy-based classification might be more practical. Instead of selecting all related posts through a manual relationship process, you apply a single taxonomy term to all related posts. Then you can create a View of posts filtered by term to display related posts from each post type.

I recommend you perform tests to see how workflows will be impacted with the numbers of posts you have mentioned.

(2) If I consider the base version of a cloudways cloud hosting (1GB RAM, 1 Core, 1 TB bandwidth), is it possible to give a very rough ballpark estimate of how many concurrent users / monthly visitors can be supported?

No, it's really not possible for me to predict performance because there are too many variables. My best advice is to set up a test site and import some dummy content. Add some post relationships between that dummy content. Then set up some Views that show related content. Then you can run some performance tests on the front-end of the site.

#1187334

Hi,

Apologies for a delayed response, I was away for the past week. Thanks for your detailed response.

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 get's 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). 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.