¿Sufres de lentitud de búsqueda en WooCommerce? Mejore su sitio con esta actualización gratuita
Este artículo apareció originalmente en Codificable.
Recientemente hemos experimentado algunos problemas graves con la búsqueda de WooCommerce en Sitios de comercio electrónico que procesan un gran número de pedidos. Es necesario consultar la tabla postmeta cuando se busca un meta_valor específico, lo que provoca un ralentización importante de WooCommerce. Por ejemplo, la consulta de la sección "mis pedidos" tardaría 5 s o incluso más, en función del entorno del servidor. Por otra parte, la búsqueda en la pantalla "Pedidos" de los pedidos pertenecientes a un correo electrónico o a una persona determinada puede durar 30 segundos o más (debido a la implicación de JOIN adicionales en la tabla postmeta).
Los dos ejemplos anteriores son inaceptables para un sitio web con gran cantidad de tráfico y debían solucionarse.
Soluciones actuales y limitaciones asociadas
Tras investigar un poco, hemos descubierto que estos problemas se tratan actualmente de dos maneras:
- utilizando ElasticSearch para indexación, con la ayuda del plugin ElasticPress, o
- utilizando una tabla de índices secundaria dentro de la misma base de datos del sitio.
La solución ElasticSearch suena bien en teoría, pero nuestra experiencia nos lleva a creer que no es una buena cosa para integrar con WordPress. Esto se debe al enorme número de diferencias entre la fuente de datos base de WP (que son tablas MySQL) y los índices de ElasticSearch.
Aunque ElasticSearch realiza muy bien las búsquedas parciales y es bastante bueno a la hora de "adivinar" lo que se pretende escribir en la consulta de búsqueda, estas pequeñas ventajas definitivamente no se ven compensadas por los inconvenientes de integrar estas dos fuentes de datos:
- latencia entre la instancia de ElasticSearch y su proveedor de alojamiento (tenga en cuenta que esto no será un problema si tiene ElasticPress instalado en el mismo servidor que su entorno PHP, pero esto no es un escenario común con las soluciones actuales de alojamiento gestionado de WordPress), y
- el número de pedidos incluidos en cada resultado (en todas las páginas) se reduce a un par de centenares.
En este caso, tendríamos que consultar la instancia de ElasticSearch y luego pasar los IDs de entradas coincidentes a WP_Query (respetando la longitud máxima de la consulta SQL que se envía a MySQL). Esto rompe el flujo de trabajo para búsquedas de amplio rango, y podría potencialmente proporcionar un número engañoso de resultados totales al administrador de la tienda que busca en la pantalla de Pedidos.
Ahora, pasemos a la tabla de índice secundaria. La solución original nos fue presentada por Patrick Garman, un compañero desarrollador de WordPress. Su intención original era simplemente mejorar la sección “Mis Pedidos” de WooCommerce, pero pensamos que esto se quedaba un poco corto para nuestras necesidades.
Sabemos que su implementación actual es sólo una solución temporal hasta el lanzamiento de WooCommerce 3.0 y la enorme renovación de la base de datos que está prevista para ello (que solucionará los problemas que estamos discutiendo en este post). También sabemos que WC 3.0 no está programado para ser lanzado hasta mediados de 2017, y ya que tenemos que hacer felices a nuestros clientes antes de entonces, hemos bifurcado la implementación de Patrick.
Nuestra solución propuesta
La implementación original del índice de pedidos sólo indexa los ID de los pedidos y los ID de los clientes en una tabla secundaria (que es lo que Patrick se propuso arreglar). Su solución es modificar la WP_Query "Mis Pedidos" para utilizar su índice.
Lo ampliamos de varias maneras:
- Hemos incluido los correos electrónicos de los clientes (tanto el correo electrónico de facturación del pedido como el correo electrónico del cliente que se deriva del cliente asignado al pedido). Siempre que busque un correo electrónico en la vista de pedidos de la sección de administración, activamos el uso del índice en lugar de postmeta.
- Hemos incluido los nombres de los clientes (facturación, envío y nombre para mostrar del cliente asignado).
Aquí nos encontramos con un problema; no queremos eliminar completamente las funciones de búsqueda existentes de WooCommerce, pero necesitamos tener alguna forma de usar el índice condicionalmente para búsquedas más rápidas. Esto se debe a que nuestro índice no soporta la búsqueda por dirección, por ejemplo, y la funcionalidad de WooCommerce cubre eso.
Para conseguirlo, hemos incluido un parámetro como búsqueda. Siempre que su parámetro de búsqueda sea "name:John D", le devolveremos todos los pedidos con nombres que coincidan con John D utilizando una búsqueda comodín. Podrías buscar por el ID del pedido en WooCommerce pero pensamos que podíamos hacerlo más fácil, así que con nuestra solución, puedes simplemente introducir el término de búsqueda "#1456" y te devolveremos el pedido 1456.
Cómo aplicarlo
Para instalar este índice, todo lo que tienes que hacer es instalar nuestro fork del plugin y luego habilitarlo. Aquí está la URL: https://github.com/saucal/wc-customer-order-index
La única complicación por el momento es que necesitas acceso a WP-CLI para crear el índice inicial. Estamos trabajando en habilitar una interfaz AJAX que le permitirá construir el índice sin WP-CLI.
Por ahora, después de activar el plugin, necesitas abrir tu interfaz WP-CLI e introducir el comando "wp wc_coi reset_index" para que empiece a generar el índice por ti. El tiempo que tarde este proceso variará en función del número de pedidos que tenga en su sitio.
Cómo han cambiado las cosas
Con el uso de este plugin, hemos podido mejorar enormemente el rendimiento de las grandes tiendas de nuestros clientes. Aquí arriba puedes ver un ejemplo en el que el tiempo era de casi 40 segundos. En uno de nuestros casos de peor rendimiento, la búsqueda de correo electrónico en WP-Admin tardaba más de 50 segundos.
Utilizando este plugin, hemos reducido el tiempo de búsqueda a menos de 5 segundos, ¡mejorándolo en 867%!
Para terminar
Probamos la solución ElasticSearch para uno de nuestros clientes y tenía demasiadas partes móviles para nuestro gusto. Preferimos algo que se mantenga dentro del ámbito de WordPress y no requiera que nuestros clientes se den de alta en ningún servicio externo.
Para ser claros, esto no es un problema de ElasticSearch como tecnología. Es sólo que es demasiado diferente de cómo funciona WordPress, por lo que la integración de los dos creó algunas desventajas que para nosotros eran deal breakers teniendo en cuenta lo que estábamos tratando de lograr. Además, tuvimos que recurrir a un complejo plugin de terceros (ElasticPress de 10up).
Hemos iterado sobre el enfoque de Patrick y lo hemos ampliado para satisfacer las necesidades más comunes de nuestros clientes. Como agencia de confianza de WordPress, sabemos que esta no es la solución más bonita, ya que duplica muchos de los datos. Sólo queremos proporcionar a nuestros clientes una solución sólida hasta que WooCommerce 3.0 sea lanzado y haga esta solución innecesaria.
¿Habrías hecho algo diferente? No dudes en enviarnos un pull request en nuestro repositorio, ¡nos encantaría ver alternativas!
¡Choca esos cinco con nuestro desarrollador principal Matias por ayudarme con este artículo!
