[Resolved] Help me troubleshoot Views/cache memory issues with host
This support ticket is created 7 years, 1 month 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.
No supporters are available to work today on Toolset forum. Feel free to create tickets and we will handle it as soon as we are online. Thank you for your understanding.
I have deactivated Views at hidden link because Bluehost said that it was killing their servers. At peak event times, the site gets 500-600 visitors at once.
However, most of the traffic was going to non-View content. Each blog post does have a View in the sidebar for a slideshow (now deactivated). The Home page had two Views (a slideshow and blog post).
With Views deactivated, the site gets all A's on speed tests. Also, Bluehost said that W3 Total Cache was causing an issue and forced it to be deactivated.
This seems counterintuitive in a lot of ways. So I wanted to get a few things cleared up first:
-Do Types or Views eat up any memory when a page/post does NOT actively load content?
-How much memory does an AJAX transition on a slideshow eat up compared to a standard HTML transition?
-Does the volume of a content template (e.g. a layout with various fields vs just a title and a link) eat up more memory? Or is the memory basically the same for every view?
Did your host give you anything more specific than "killing their servers"? If Views was creating issues I would expect it to be in server requests more than memory usage, per se.
Do you have a copy of your site on another server, e.g. locally, where you can do some testing?
This shows all of the database queries run on any particular page. You may find that Toolset does make some queries even on pages where there is no Toolset content added (because content could be added on any page), but the queries will mostly relate to the content being added itself. If you have a page where you output two custom fields that will require two queries to retrieve the values. If you have a page where you output fifty custom fields, that will require fifty queries to retrieve the values. (Those these a simple retrieval queries.)
When you add a slider View that retrieves the matching content, then makes repeated queries every few seconds to update the slider via ajax. That would be the case whether you were using Views or whether you wrote your own PHP slider, and it may be the case that on a high traffic site with 500-600 concurrent visitors each polling the database to update a slider every few seconds you are asking too much of the server available on your plan.
Views does make extensive use of caching internally, by the way, to reduce the burden on the server.
Try checking the results of the Query Monitor plugin and see if it is throwing up any warnings about slow queries that might narrow down any issue. If you need some help interpreting the results let me know.
Please keep this thread open for a bit. We haven't reactivated Toolset yet because it's at a peak period and I don't want to break things., unless you think it's better to troubleshoot while experiencing peak traffic. Otherwise, I'll be troubleshooting a bit more next week. I've already removed the slideshows (home page and child page / sidebar).
What are the most obvious items to look for in Query Monitor when I activate it? Right now, it's registering 6 background queries through Types on a standard blog post without any active Views/Types data. What's a number that would raise a flag in terms of overwhelming the server? Is that number typical for simply having Types activated and several CPTs created, though nothing called out on a page?
Re: "overloading the server", it was all database connection errors and that we needed to "optimize the WordPress code." However, images are compressed (using WP Smush) and pages were cached (using W3 Total Cache).
As I mentioned before, they thought that W3 Total Cache was a large part of the problem. They recommended WP Optimizer instead. I'm waiting until after the peak period to try it.
Also, I attached a screen shot of their internal diagnostics. Prior to all of this happening, though, the site got scores of A's and B's on various speed testing websites.
I took my time getting back to you as the queue was very busy over the weekend and it sounds like you may need some time before you are ready to do much more testing.
Having said that, much of your testing can be done on a duplicate of the site on another server, including testing locally.
I don't have specific guidelines as to what you should expect to see if using Query Monitor. The extremes of what's excellent or what's very poor are easy to spot, but most sites fall in a grey area in the middle where the results are less obvious.
As a quick benchmark I ran a test locally to see what Query Monitor showed for a vanilla WooCommerce site with the demo content installed. To load the shop page total query time was 0.89s, involved 39 queries, of which one was identified as being slow (a get_terms call by WooCommerce, unavoidable because of the WordPress design of the database tables for taxonomies).
I used Toolset (Types plus Views plus WooCommerce Views) to create a custom product archive to display in place of the standard WooCommerce shop. It was, expectedly, slower, but not drastically so. The full result took 1.09s, involved 58 queries, one of which was identified as slow (the same query, this time originated by the WooCommerce Views plugin).
By coincidence a good article on digging deeper into the topic landed in my inbox this morning, which you might want to read: hidden link.
I don't know much about your site but I have to say that having 500-600 hundred concurrent users of a dynamic site will be very demanding of the server, and part of your strategy may require eliminating resource-intensive content. Using Query Monitor should help you identify what is weighing most heavily on your server, but you will also want to employ other performance enhancing tricks such as using a CDN wherever possible. You can read more about hosting Toolset assets on a CDN here: https://toolset.com/documentation/programmer-reference/toolset-resource-directories-for-cdn-upload/
I'll mark this thread as awaiting feedback from you, which should give you a week or so before needing to comment to keep it open.
