This is a test result I just did with the same view posted on a page one, two and three times.
There are 34 items found in this view, and each item has 3 relationship fields and 11 normal fields.
I revisited the local copy of your site I have installed, with just Types and Blocks active for testing.
I'm using this page for testing: /mens-event/egna-spring-trophy-2019-5
It includes the View id=1320 which is one of the Views listed previously as being problematic.
With the previous version of Blocks according to Query Monitor that page was taking over 10s to assemble the page in query time and involved over 500 queries.
After updating to Blocks 1.3.3 the number of queries more than halves (to 253) and the time shrinks to 3.7s. That's not fast, but it's a complex page, and is a big improvement on the previous version.
That's not the experience you are reporting.
Can you give me specific details of the tests you are doing that I can reproduce locally to compare?
First off the update has dropped a legacy code which you may not have noticed. This will be part of the reason you are seeing an improvement in time.
If the test page you mentioned is showing the names as just text and not a link, then you will have to update View id-=1320 ....at the bottom on the list of templates .... "Mens Find profile".....change TO the following code.
Similar adjustments will have to be done to the other disciplines . As this will effect the number of relationship fields in the view, and thus increase the time.
My numbers from my last message are from this test page : /ladies-event/11th-santa-claus-cup-2017-6
(why would the same view be so much slower the first time vs the 2nd and 3rd time?)
but with the following adjustment for testing :
1 - use the "front end layouts editor " - "edit layout on back-end" - "ladies events layout"
2 - then edit admin-testing ..... remove all the code within the access setting and add this code one two or three times when testing (note you will have to do a similar adjustment as mentioned above, but for "ladies find profile" template)
[wpv-view name="ladies-free-skate-results"]
Staying with the layout:
If you want to see my full problem with this page go to "tabs row" and change the 1st line to Administrator access (but don't forget to change the access setting for "admin-testing" to something like Contributor).
The "temp-final only" is what i have set up for members until this problem is fixed.
Hope you can follow all this, and see the same issues I am.
p.s. I have been making a lot of minor adjustments to my coding since to improve the overall total page time but these 3 main views are still the main issue. There are other similar views on the skaters profiles but they should be all part of the same problem.
Good Luck!
The changes for this you shared above are changes that you've made yourself to the site while trying to resolve this?
(By the way, if it hasn't been said already, I'm sorry that you are having to go through this just to restore the site performance to how it was before. I appreciate that where I'm talking about improvements in the number of queries and load times, these are compared to the benchmark when the problems were introduced, not to how your site was before migrating. Obviously we introduce such changes with the intention of improving things, not making them worse, and there's nothing like testing on complex real-world sites to reveal where we overlooked cases.)
I tried to log back into your site using the credentials you shared earlier with Jamal, but the user doesn't appear to be an admin, I can't access the back end.
I was going to update my copy of your site (I used All in One WP Migration, Duplicator got stuck), just the database, so that I have the changes you've subsequently made.
Could you export just the database (using All in One WP Migration) and share the file with me?
Or update the test user so that I have admin rights and I can do it myself?
The changes I have been making are more overall improvements to the site. It still does not resolve the 3 main views on the pages (Final results - short and free).
Another test you can do is remove the relationship codes from your id 1320 (name, nation and flag) then you will see the major time improvement.
p.s. - sorry I missed your question.... that legacy coding no longer works. It has nothing to do with resolving this issue. It just brings it back to the same state.
This new version has ladies-event restored back to showing the full required content. The previous version was showing a limited amount for testing purposes. Its best to do your testing with this as they will have a higher item count and thus a higher render time. Overall the item count can range from 1 to 50 with the average around 20.
From all my testing over the past month I keep coming up with these two key points.
1 - The views that are effected have relationship fields in the view loop.
2 - The worst render time is always the FIRST view on the page that has relationship fields in the view loop.
Remove the relationship fields from the first view and the overall time stays the same but now the 2nd view has a higher render time (because it is now the first view with relationship fields).
I've done some more checks and testing on the ladies-event pages, where I can see the problem with the render times for the Views (in particular the first View, as you mention), and where Query Monitor reports about 50 slow queries, all involved in retrieving data about related posts.
I've prepared a slimmed down version of the site to pass back to our developers to take another look at this, and I'll update you again when I get some feedback from them.
The Views and Types developers are collaborating on this (Views uses the Types API to retrieve related posts but then has its own layer on top) and it looks like they've identified various optimisations that can be applied (nothing like testing on a fairly complex real-world site), but they haven't yet finished, because any further updates need to go through QA testing etc.
But I can see it is very much in hand, and we should have an update for you soon. (There will be hotfixes for a few issues that arose with the WP5.6 releases probably later this week, hopefully this will be included.)
We've just published updates to several plugins, including Types and Views/Blocks, and those include a lot of work on query optimisation based on profiling your site (and others). I'm hesitant to say it's fixed, and I know the devs think there may be one or two areas where they can make improvements, and that work is ongoing, but if you update you should see a clear difference.
First test was worse ... around 1min to render.
After some tweaks with the views Query Options.... turning it off or on .... it came back down to around 30sec. So first question, should I have it checked to "Don't include current page in query result" or not ???
Also for the Query Filter Option, is it best to use "the current post in the loop" or "the post where the view is shown" ?
I have noticed an increase in render times now for some of the 2nd views on the page. As I mentioned before, this happens if improvements are made to the 1st view (the time shifts to the 2nd).
Another thing I have noticed recently even before this update, the other disciplines (mens, pairs, dance & synchro) seem to have better render times then the ladies. Yes the ladies have more items on average but if you compare with similar item counts the ladies appears to be worse. Keep in mind the basic setup of the views are identical. (late thought) Maybe that's because of a larger data base to search from, for the ladies.
Overall, if the view has a lower item count of posts, it is getting better, but the more items found say over 20 or so, not so much.
How was your testing on the copy of my site ? Did you notice any improvement ?
Sorry for such a poor report, but I know the devs will find a solution ..... and as you said ... the work is ongoing.
I've updated the plugins on my local copy of your site, and on the ladies event pages I'm getting a total page load time of about 10 seconds, so slow, but nothing like you are seeing. However, for testing I do have everything except the key Toolset plugins enabled, and for creating the site copy to share with the devs I did remove about 80 custom database tables created by other plugins, so this test version is very much a best-case scenario.
I've discussed again with the devs at this morning's meeting, and the lead developer wants to go through some specific examples that are the most problematic to get to the root of the cause(s). They think that the code has been mostly optimised as much as it can be, and likely improvements will probably come from changing settings or changing the shortcodes and attributes. I think I'm right in saying this site would have originally been set up with Types 2 relationships, then migrated to Types 3, and then migrated again to Types 3.4, and it may be a mix of the old and the new together which is introducing the inefficiencies.
So, can I ask once more for some specific links to particular pages or individual posts that you find are most problematic, and I'll share those with the dev, who will either identify any further code changes we can make, or come back with some suggestions for how to update the settings etc. to make the queries work most efficiently.
For example, this is the post I was just checking, that took about 10s: /ladies-event/4th-edusport-trophy-2020-2
Your correct in your assumption of being set up with types 2 (possible earlier 1.8 or so), but the real work started around types 2 (late 2015 to early 2016). All first set ups and testing was with the ladies then copied to the others and modified to fit them.
For the post you checked I get the following :
Items found : 14
Total Page : 12.94
View 1316 : 7.56
View 1355 : 3.19
View 1356 : 0.70
These are the key 3 Views for ladies-events (but they search ladies-results)
This sample has about a max amount of items, and the worst case that I use for testing. hidden link
This is my current readings :
Items Found : 48
Total page : 36.65
View 1316 : 23.06
View 1355 : 9.98
View 1356 : 2.14
Just as I was about to finish this post I discovered what might be a break through (I hope). You got me thinking about test pages and early days, so I thought what about the very 1st ones I did.
Try this page hidden link
This page does not follow the pattern of first view worst and 3rd view best. (plus for 16 items not bad from what I have seen), plus much better then your test page with similar item count.
Item found : 16
Total: 8.7
1316 : 2.02
1355 : 4.36
1356 : 1.09
So maybe its just more recent posts that are the worst and older ones are better. I will do some testing on that theory. (plus I'm seeing some new bugs on these older posts maybe my old coding, coming back to haunt me)
There is definitely, something up with older posts being much better than newer posts.
You can go to the back end and look up the ladies events and sort by post dates to do your own testing.
Just a theory BUT could it be an issue maybe during the data base upgrade that may have caused this ? Like updating the early posts and stopping part way through. I may be out in left field, but just a thought.
