Skip Navigation

[Resuelto] Super slow rendering of CRED taxonomy search fields

Este hilo está resuelto. Aquí tiene una descripción del problema y la solución.

Problem:
Is Toolset PHP7 compatible?
Solution:
Not as of yet, but we do have a temporary fix.
Relevant Documentation:
https://toolset.com/errata/views-compatibility-issue-with-php-7/

This support ticket is created hace 8 años, 6 meses. 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.

Hoy no hay técnicos de soporte disponibles en el foro Juego de herramientas. Siéntase libre de enviar sus tiques y les daremos trámite tan pronto como estemos disponibles en línea. Gracias por su comprensión.

Etiquetado: 

Este tema contiene 3 respuestas, tiene 2 mensajes.

Última actualización por margaritR hace 8 años, 5 meses.

Asistido por: Ross Fisher.

Autor
Mensajes
#354900
Screenshot from 2015-12-21 12:04:25.png

I have 2 main custom taxonomies. `location` and `listing_category`, both hierarchical. I have ~ 4k terms in location and ~1k in `listing_category`. I am using the imported `Parametric ads search` view(came with classifieds demo site).

My field shortcodes:

[wpv-control taxonomy="location" url_param="loc" type="select" default_label="all locations" taxonomy_order="ASC" taxonomy_orderby="name" hide_empty="true"]

[wpv-control taxonomy="listing_category" url_param="listing-category" type="select" default_label="all categories" hide_empty="true"]

These two adds up to 9 seconds of load time. I instrumented my load process using some of the main actions as checkpoints.

[21-Dec-2015 09:25:33 UTC] [muplugins_loaded] 0.211 seconds (start)
[21-Dec-2015 09:25:34 UTC] [set_current_user] 0.682 seconds (took 0.471s)
[21-Dec-2015 09:25:34 UTC] [plugins_loaded] 0.694 seconds (took 0.012s)
[21-Dec-2015 09:25:34 UTC] [setup_theme] 0.695 seconds (took 0.001s)
[21-Dec-2015 09:25:34 UTC] [after_setup_theme] 0,752 seconds (took 0.058s)
[21-Dec-2015 09:25:34 UTC] [wp_default_scripts] 0,797 seconds (took 0.044s)
[21-Dec-2015 09:25:34 UTC] [wp_default_styles] 0,802 seconds (took 0.006s)
[21-Dec-2015 09:25:34 UTC] [wp_default_scripts] 0,908 seconds (took 0.106s)
[21-Dec-2015 09:25:34 UTC] [widgets_init] 0,915 seconds (took 0.007s)
[21-Dec-2015 09:25:34 UTC] [init] 1,060 seconds (took 0.145s)
[21-Dec-2015 09:25:34 UTC] [wp_loaded] 1,064 seconds (took 0.004s)
[21-Dec-2015 09:25:34 UTC] [wp] 1,070 seconds (took 0.006s)
[21-Dec-2015 09:25:34 UTC] [wp_head] 1,109 seconds (took 0.040s)
[21-Dec-2015 09:25:34 UTC] [loop_start] 1,127 seconds (took 0.017s)
[21-Dec-2015 09:25:43 UTC] [loop_end] 9,976 seconds (took 8.849s)
[21-Dec-2015 09:25:43 UTC] [wp_footer] 10,005 seconds (took 0.030s)
[21-Dec-2015 09:25:43 UTC] [shutdown] 10,006 seconds (took 0.001s)

You can see the major load time is taking place between `loop_start` and `loop_end` actions 8.8 out of 10 seconds. Also I can tell this is not due to slow DB request (attached screenshot). This leaves me with the impression that parsing CRED shortcodes is causing this huge load time. Please investigate.

#354908

Forgot to mention that after removing the above shortcodes load time dropped to the reasonable ~ 1-1.2 seconds total, so it's them causing all the trouble.

#355031

Thank you for contacting Toolset support, I'd be delighted to assist!

I know how important it is for your site to load in under 2 seconds, some users may tire of waiting and stop using your site which isn't something anyone wants!

I appreciate your troubleshooting information, it's very helpful for me to pass this along to our developers. I agree that your Database is reporting back very quick, it's the parsing of the array via PHP that is the slowdown. Off the top of my head, PHP 7 is tested to be 2x faster however we are still working on compatibility.

What would be nice is to be able to use only a subset of your taxonomies for rendering on the frontend, that way we aren't asking PHP to parse 4k taxonomy terms everytime it loads parametric search. Would it be possible for you to split up your taxonomies?

One last thing, be sure you have opcache enabled, it can help PHP speed up repeat executions such as this, https://wordpress.org/plugins/opcache/ can help you find a good value for how large your opcache needs to be. I recommend 128-256MB

opcache.memory_consumption=256
opcache.interned_strings_buffer=8
opcache.max_accelerated_files=4000
opcache.revalidate_freq=60
opcache.fast_shutdown=1
opcache.enable_cli=1

The above config works well for me, let me know your results or thoughts!

#355180

Opcache is already on. Don't know if splitting the taxes is an option but is something to think about. For now the only thing that seems to help is using persistent cache, dropping load times to ~ 2.2 sec which is still far from ideal. Please make sure your plugins get php7 compatibility soon.

Este ticket ya está cerrado. Si eres cliente de Toolset y necesitas ayuda relacionada, abre un nuevo ticket de soporte.