Hi Adriano,
I'm running 2.1 on my staging site to check performance prior to upgrading my production site.
I'm working on a combined filter/display view that will replace some of the split parametric search+display views I use.
I am experiencing several issues:
#1. The initial page load is quite slow on Views 2.1
The page has to load the taxonomy for the CPTs and put these into a checkbox field for the user to select from (the checkbox fields and other filtering fields are under an accordion/tabs nested structure).
As the size of my database and taxonomy list grows the delay on page load has reached an unacceptable level to end users.
It can take 45 seconds or more for a page to load before the view is rendered (page ready) on my staging site.
On my production site (which is still running pre 2.0 views and the split para / display views setup) the delay has been unacceptable to users for a while (as the size of the taxonomies grew).
On my staging site I also see warnings from DB access such as...
Error while sending QUERY packet. PID=32063 from wp-includes/wp-db.php:1811
#2. Pagination can seem to not respond (no spinner) and will just sit in "zombie" state but eventually advance
When pagination does eventually proceed sometimes the spinner comes up much later just before the view animates the view items transition.
The page cache setting changes at which click the system goes into "zombie" behavior.
So it is the point at which Views has to fetch more pages that the "zombie" behavior appears.
I will provide you access to my staging site and you can look at the view that is currently setup for the single search/display view configuration.
Send me a private message and I'll send the credentials.
Thanks,
Bob
Hello,
I'm sorry for the delay. I'll need to talk with our Views development team about it. I'll let you know as soon as I hear something.
Please share credentials as you said. Private area is enabled.
Thanks. I can see the issue. I've changed your View settings for "Always show all values for inputs" because "Show only available options for each input" is very expensive, how is it now for you?
Hi Adriano,
Thanks for the feedback.
I was aware that the setting could be changed to "Always show all values for inputs" to remove a significant part of the backend processing load.
That was my fallback option plus perhaps some trimming of taxonomy terms to improve even the faster setting.
However, setting "Always show all values for inputs" presents a less user friendly UI since when filtering a subset of the data-set taxonomy terms will be rendered that are not attached to the subset data.
Hence checking a box will result in zero items being rendered in the view image display area.
I raised the performance issue so that there could be some investigation of the potential to improve the backend efficiency for the configuration where dependency (or taxonomy count) is used.
Both of these cause the system to go into long processing delays in the backend for what is not really a very large taxonomy.
Also note that the pagination spinner issue still exists even with "Always show all values for inputs" set.
Try using the staging site some more with various filters and such and you will find instances where you click navigation but the spinner does not appear until just before pagination animation starts.
This could be that the JS/JQ code that starts the spinner is late in the code thread or perhaps the browser blocks sometimes during AJAX?
I just don't have time to go digging into 'wpv-pagination-embedded.js' to check out that theory.
Thoughts?
Thanks,
Bob
Hey Bob,
I've raised your comments to our development team. We have plans to improve the performance of this and we will do our best to improve this soon. I have no ETA for now, we are about to release, I'll suggest them to think on this next release. Thank you for raising this, you are not the only one asking this.
OK on discussion with dev team.
Can we leave this ticket open pending feedback on if/when improvement might be made.
Thanks,
Bob
Hi Bob,
Adriano is not available now, It will be a pleasure if you don't mind that I replace him in this thread.
I've contacted the development team regarding this and they said that this will be a bit difficult but they will try to fix this performance issue.
Also, this is now included in our to-do list and it's scheduled to be handled in Views 2.3 which is the next release and in the current development cycle.
Please let me know if you are satisfied with this reply.
Also, you can keep this ticket open and I will notify you once we launch this release.
Thanks.
Thanks Mohammed.
It is definitely a performance improvement that I would appreciate.
As you know without the dependency capability there are filter items that will produce a zero result even though they are there to select.
This is a less than satisfactory user experience.
I'd also like to be able to use the %%COUNT%% feature and that too depends on the backend performance being rectified.
Thanks,
Bob
Hi Bob,
Thank you for the feedback.
Could you please open a new ticket for the %%COUNT%% feature so that it can be handled by our development team?
Hi,
We've just launched a new Toolset release.
Could you please update all your Toolset plugins and test your issue?
Thanks.
Hi Mohammed,
I've tested the new release on my staging site.
The performance has not improved when using the dependency setting for "Show only available options for each input" in a view.
The load time now seems worse when opening the page with the view (>60 seconds) .
Filtering the View into a subset is totally unusable. I gave up timing after 10 minutes and eventually (maybe 15 minutes later) the view rendered.
These results indicate that performance seems to be worse than before.
I have not added posts to the staging site so it is not like there are more posts or taxonomy terms to filter/match since the incident report was originally submitted.
Also the issue with the frontend spinner being delayed on pagination remains as well.
What now?
Thanks,
Bob
Hi Bob,
I'm checking the issue with the Views plugin developer.
Please wait and I will get back to you again.
Thanks.
Hi Bob,
I tried many times to replicate the issue again but I couldn't.
Your issue is a special case and to be able to debug the problem I’d like to replicate your site locally. For this you'll need to temporarily install a plugin called "Duplicator" on your site. This will allow you to create a copy of your site and your content. You can provide me with the snapshot following these directions:
If you already know how Duplicator works ( http://wordpress.org/plugins/duplicator/ ), please skip the following steps and just send me the installer file and the zipped package you downloaded.
:: Duplicator instructions
. From WordPress plugin page, look for "Duplicator" and install it
. Once installed, you get a new main menu "Duplicator"
. Chose "Packages"
. Click on the first button you find in the toolbar on the right ("Create Package")
. Give it a name or leave it as is
**You can ignore the uploads directory , cache and the archives
. Click on "Create Package Set"
. Wait until the package is ready
. Click on "Installer", then on "Package": the first one is just a php script, the second one is a zip file containing everything you need
. Send me both files (you probably want to use DropBox, Google Drive, or similar services, as the snapshot file will be quite big , you can also exclude the images if the file is very big )
IMPORTANT: remember to create or keep an admin account for me before creating the snapshot, or I won't be able to log-in. You may delete the new admin account once the snapshot has been built.
I will set the next reply as a private reply so you will able to provide a link to download the duplicator package.
I will be nice if you mentioned the pages where the issue is being replicate and any information that helps me to debug the issue.
Thanks and Best Regards
Hi Bob,
I see that the PHP version installed on your server is 5.6.29 which is too old.
The latest stable version now is 7.1.2 . for me, I'm working daily on websites and I was woking on the same version like yours.
When I updated to php 7.1.2 , the localhost speed increased too much.
Could you please upgrade php, MySqsl and apache to the latest versions?
Please test the issue with the latest versions before I start taking a snapshot because it will take too much time.
Thanks.
