Skip Navigation

[Closed] wpv_get_view_query_results using too much server resources

This support ticket is created 3 years, 7 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
9:00 – 13:00 9:00 – 13:00 9:00 – 13:00 9:00 – 13:00 - - 9:00 – 13:00
14:00 – 18:00 14:00 – 18:00 14:00 – 18:00 14:00 – 18:00 - - 14:00 – 18:00

Supporter timezone: Africa/Casablanca (GMT+01:00)

This topic contains 2 replies, has 2 voices.

Last updated by Jamal 3 years, 7 months ago.

Assisted by: Jamal.

Author
Posts
#1781835

Tell us what you are trying to do?
optimize our views

Is there any documentation that you are following?
sure

What is the link to your site?
hidden link
flywheel
two-acorns

Our server administrator gave us the following feedback:
"

Looking over the server, we're seeing instances on both the Staging and Production sites in which the site has been exhausting its resources (not just its memory), resulting in some ongoing slowness and stability issues on the server.

I dug into why this was occurring and it appears to mainly stem from the site leveraging uncacheable POST requests to the server's backend in order to update the page's information by calling wpv_get_view_query_results. Essentially this means that per-pageview the server is getting hit by WPViews in order to add +1 to the current count of the page views, something which is frowned upon for performance and stability, since tools like Google's Analytics can accomplish this without the need for putting strain on the server itself.

The problem with this is that the site appears to spawn these POST requests frequently, and based on my findings it appears to happen per-visitor, per-pageview. This is less than ideal because if every single visitor to the site is spawning hits to the server's backend then development of the site has created a situation in which the server's overall stability is directly tied to the amount of traffic the site actively has at any given time. This is a bad place to be since traffic influxes can topple the server and lead to slow response times (504 errors) or even site outages (502 or 503 errors).

I like to use the analogy of a restaurant to help illustrate. Think of the server like a restaurant and within it there is waitstaff (processes). If too many food orders (uncached requests from visitors) come in at the same time, there will reach a point at which your waitstaff (server processes) can't physically keep up with the demand. When this happens a queue forms, and orders (requests) must wait for a brief period before a waitstaff (process) becomes available to help fulfill it. If the frequency is too high, or if the requests are too complex, this queue can continue growing over time as the slowness grows, eventually causing issues (503s) if it grows too long.

The two options available to help reduce these issues from happening would be to either reduce the number of concurrent uncached requests to the server or to increase the server resources (or both!). I've increased those resources for you, to try and help out, but for the best results you're going to want to also review the site and reduce the uncached requests, ie: likely remove the WPViews counter and look for alternative tools for view tracking.

Let me know if you have any additional questions, we're always more than happy to help.

"

Can you please help us optimize this?

#1782289

Jamal
Supporter

Languages: English (English ) French (Français )

Timezone: Africa/Casablanca (GMT+01:00)

Hello and thank you for contacting the Toolset support.

"wpv_get_view_query_results" is our AJAX endpoint to load the results of a view, either after pagination or after filter/search. I would say that one of your views is taking too much to be executed. This, usually, comes for views that have nested views inside of it, because of the database queries that will be executed inside the loop, for each post of the loop.

Toolset allows views to be cached, but Toolset will invalidate the cache when a post is updated(created/deleted/modified), so the next visit will not use the cache, but instead, it will execute the view again.
I understood from the server administrator message, that something is updated in each visit(visits counts), this could invalidate the cache and force the view to be executed again.

To better assist with this issue, I'll need to take a closer look at your page to have a better understanding of how it was implemented. Your next reply will be private to let you share credentials safely. ** Make a database backup before sharing credentials. **

#1786265

Jamal
Supporter

Languages: English (English ) French (Français )

Timezone: Africa/Casablanca (GMT+01:00)

The page does not contain any nested views or a view that can be complex too much to be generated in a long time.

I would say that the number of used plugins and the theme contributes to this, but I'll need to run additional tests.

Would it be possible for me to take a copy of your website for some local debugging? If you agree, I'll install the Duplicator plugin and will take a copy of your website. Let me know you answer.

The topic ‘[Closed] wpv_get_view_query_results using too much server resources’ is closed to new replies.