Desde hace dos meses venía experimentando problemas en la página, el servidor se saturaba bastante y aunque lo cambiaba a otros servidores más holgados, el problema persistía e incluso iba a peor. Había llegado al punto que, desde una instalación de WordPress limpia, tan sólo restituía la base de datos y el servidor se saturaba a tope.
La barra de consumo de CPU se disparaba hasta el 100% y el servidor se quedaba colgado, quedando todos los servicios inaccesibles. Así que comencé a eliminar posibles culpables. No parecía ser ningún plugin, ni la plantilla, plugins de caché, ni un servidor mal configurado… El problema parecía residir en la base de datos, nada más restablecerla, el servidor se colapsaba.
Entonces pensé si existiría algún registro corrupto en la base de datos, de modo que eliminé tablas culpables. Al parecer la de los posts (wp_posts) podría ser una de las candidatas, o al menos el error ocurría cuando las entradas del blog aparecían.
Tras muchas pruebas, descubrí que el error aparecía exactamente cuando actualizaba la estructura del permalink del blog, que es la que determina cómo se mostrarán las URLs en la sección AJUSTES > ENLACES PERMANENTES. Por ejemplo, yo venía utilizando desde siempre /%postname%/%category%/
Lo que creaba URLs de este tipo:
https://www.blogodisea.com/chistes-para-reir-a-mansalva/chistes/
O sea, mostraban el nombre del post y la categoría. Luego averigüé que cada vez que empleaba esta estructura, el blog se desmadraba y consumía muchos recursos.
Pero si empleaba otras como:
Predeterminado – https://www.blogodisea.com/?p=123
Día y nombre – https://www.blogodisea.com/2011/06/24/sample-post/
Mes y nombre – https://www.blogodisea.com/2011/06/sample-post/
Numérico – https://www.blogodisea.com/archives/123
El blog funcionaba bien y no se saturaba.
De esta manera determiné que la estructura de los permalinks era la causante, aunque esto no me había sucedido con anterioridad. Creo que con tanto cambio de servidor, algo se debió de desajustar en la base de datos y provocaba estos problemas con la forma de estructurar las URLs.
Otra sospecha recayó en el peso de la base de datos, que quizás ha crecido un poco cada vez más (ahora va por los 67 megas). La verdad que también ha sido la primera vez que no pude exportar la base de datos entera, sino que tuve que hacerlo de manera separada por tablas, de modo que no pesara mucho cada grupo.
Un artículo que encontré muy interesante, especificaba que ciertas estructuras de permalinks son ineficientes y hacen trabajar mal al servidor.
WordPress ofrece una gran flexibilidad a los creadores de páginas para determinar las URLs. Existen varios atributos que pueden ser empleados y ordenados como uno quiera. La estructura de permalink correcta que viene por defecto es esta:
/%year%/%monthnum%/%day%/%postname%/
Que crea la siguiente URL de ejemplo:
http://example.com/2010/06/22/hola-mundo/
Existen diferentes etiquetas que pueden utilizarse para configurarla: %year%, %monthnum%, %day%, %hour%, %minute%, %second%, %postname%, %post_id%, %category%, %tag%, y %author%. Como se comentó antes, otorgan una gran flexibilidad para modificar la forma en que las URLs aparecen. Pero según Ryan Boren:
«Se crean reglas complicadas para estructuras con %category%, %tag%, %postname%, y %author%. Lo mejor es evitar dichas estructuras.»
Esta otra importante nota fue añadida a la página de codex sobre cómo utilizar los permalinks:
Por motivos de rendimiento, no es buena idea empezar nuestra estructura de permalinks con la categoría, tag, autor o nombre del post. La razón es que esas son reglas de texto, y emplearlas al principio de nuestra estructura del permalink hacen que WordPress se tome más tiempo para distinguir las URLs de las entradas, de las URLs de las páginas (que siempre emplean el texto «page slug» como URL). Para compensar, WordPress guarda un montón de información extra en su base de datos (tanta que sitios con muchas páginas han experimentado dificultades). Por lo tanto, es mejor empezar nuestra estructura de permalink con un campo numérico, como el año o la ID del post.
Esto supone un problema para cualquier CMS dinámico, no sólo WordPress. Si no existe una manera de reducir la información en la URL y encaminarla a una página específica o un post, el sistema deberá ejecutar un montón de búsquedas en la base de datos para encontrar la entrada correcta. Otto explica otro hipotético caso:
Creo que esto merece ser tratado. Consideremos un permalink como %category%/%postname%
De esta manera obtienes una URL como /micategoria/mipost. Se empieza analizando micategoria y mipost, pero no se sabe lo que son, ya que son simples cadenas literales para WordPress. De esta manera, primero debemos averiguar qué es micategoria.
Entonces preguntamos si micategoria es una página (no una entrada) de la tabla de wp_posts, donde post_slug = micategoria y post_type = pagina. No se encuentra nada.
Siguiente. Preguntamos a ver si micategoria es una categoría. Entonces se busca en wp_terms junto a wp_term_taxonomy (term_id = term_id) donde term = micategoria y taxonomy = category. Aquí encontramos micategoria, así que ya hemos dado un primer paso. Desafortunadamente, hasta el momento sólo sabemos que eso es una categoría, lo que no nos sirve de nada para saber dónde está el post que buscamos. Así que ignoramos la categoría.
Ahora vamos con mipost, así que de nuevo empezamos las preguntas:
1- ¿Es una página? Se busca en wp_posts donde post_slug = mipost y post_type = page. Nada.
2- ¿Es una categoría? Se busca en wp_terms junto a wp_term_taxonomy (term_id = term_id), donde term = mipost y taxonomy = category. Nada.
3- ¿Es un post? Se busca en wp_posts donde post_slug = mipost y post_type = post. ¡Por fin!La meta final es determinar específicamente qué post se ha pedido. La categoría no es de ayuda en este caso, y debemos hacer dos llamadas a la base de datos tan sólo para averiguar que podíamos haberlas ignorado. Cinco llamadas a la base de datos tan sólo para determinar de qué post se trata y su estructura. Cinco llamadas, dos de ellas de gran costo (las llamadas combinadas consumen más recursos). Y esto debe ocurrir en cada carga de página de tu sitio…
Aun así, Otto también explica que WordPress no trabaja exactamente de esta manera. Cuando WordPress detecta que poseemos una estructura de permalink ineficiente, guarda una reglas de escritura extra en una opción de la base de datos, a la que se llama cuando se presenta la página.
Para terminar, observemos dos ejemplos:
Mal
/%postname%/%post_id%/
/%category%/%postname%/Mejor:
/%post_id%/%postname%/
/%year%/%category%/%postname%/En conclusión, cuando determinemos la estructura de permalinks al crear un sitio, escoger con cuidado puede ayudar a WordPress a localizar nuestros artículos de una forma más eficiente.
Así que al final empleé la estructura:
/%year%/%postname%/%category%/
Sé que no es la mejor, de cara a SEO viene mejor la que tenía antes (/%postname%/%category%/), pero no se puede hacer más después del problema que tuve. No sé si ha resultado ser que la base de datos ha crecido, si algo se desajustó en la copia de la base de datos, o que esto de la estructuración del permalink no es para tomárselo en broma y es realmente importante. Quizás el tiempo me dé la razón y sea mejor haber hecho ahora esta reestructuración de los permalinks, antes de que la base de datos crezca aun más.
Para no perder la indexación de Google y que los enlaces no se rompan, he empleado el plugin Dean’s Permalinks Migration, que redirige las entradas con la estructura antigua, encaminándolas a las entradas correctas. De esta manera, si existe algún enlace exterior (que actualmente estará mal), el plugin se encargará de corregirlo. Google tardará más o menos un mes en re-indexar todo el blog correctamente y deberé tener el plugin siempre instalado para que no se rompan los enlaces externos que haya recibido el blog en sus dos años y medio de vida.
Sé que no he solucionado el problema realmente, las bases de datos no actúan así generalmente. He mudado muchos blogs y nunca una base de datos me dio este problema, ni siquiera en el tema de los permalinks. Así que supongo que de momento he parcheado el problema, pero me gustaría saber si alguien sufrió el mismo percance.
Me alegra mucho que ya funcione Blogodisea, Andrés.
Parece increíble que lo hayas solucionado cambiando la estructura del permalink. Y menos mal que existe ese plugin para redirigir las entradas.
Un abrazo.
Andrés me impresionas con todo lo que sabes sobre estos rollos. Mira que eres un buenazo.
Me alegro que blogodisea ya esté de regreso :) luego de lo que ha sido una verdadera odisea XD
Gracias a los dos. Pues sí Maesin, ha sido una odisea de una semana y pico, estaba desesperado y ya pensaba que tenía que volver a meter post por post para restablecer el blog. Vamos, para pegarme un tiro XD.
Me alegro mucho de que hayas podido arreglar Blogodisea, la verdad es que en esos pocos días, te he echado bastante de menos.
Gracias Conchi, un abrazo.
Hola Andrés, está muy interesante tu información. Te comento que yo tengo el mismo problema y he buscado por toda la red y me encuentro con diferentes recomendaciones, que van desde la reducción de calidad en la imágenes, los hotlinks, themes, base de datos, tags, etc, pero no sé cómo encontrar ¿cuál es exactamente lo que esté generando todo esto?, alguna recomendación?.
Gracias. Un saludo!
Hola Kev, como he dicho, posiblemente sea la estructura de los permalinks, debes cambiarlas y meter otra cosa a la que tienes ahora. Yo en mi caso tenía /%postname%/%category%/ y ahora le puse el año por medio /%year%/%postname%/%category%/. Si pruebas y el blog te empieza a andar bien con esta estructura, déjala entonces. Había tal diferencia de tener el blog sobrecargado a que de repente funcionara bien sólo por eso, que notarás la dieferencia. Si eso no te lo soluciona, ya es que pueden ser miles de cosas, es un tema algo delicado porque intervienen muchos factores. Suerte.
Hola Andrés, la verdad te doy las gracias aunque sin saber si aun funcionará esta opción de corrección en sitios WordPress en 3 sitios que tengo dado de baja por problemas de procesador, pero valdrá la pena probarlo y así será!
Apenas termine de ralizar dichos cambios y volver a subir los sitios estaré volviendo a agradecerte, funcione o no! Ya que esta opcion de solucion aun no la habia leído.
Ahora una consulta crucial. Debo solo cambiar el permalinks e instalar dicho plugin para redireccionar solamente? o tengo que realizar alguna otra cosa en la base de datos anteriormente?
Desde ya agradezco tu dedicación y predisposición a encontrar soluciones a problemas! Aguardando tu respuesta te saludo!
Con sólo cambiar los permalinks e instalar un plugin que te redireccione los permalinks antiguos bastará. Para ello, apúntate algunos ejemplos de URLs antiguas y entra en ellos con la nueva estructura, asegúrate de que la redirección funcione (lo mismo no funciona).
Por cierto, este artículo lo escribí hace tiempo y luego volví a cambiar los permalinks por unos simples (sin categoria ni año), así que nunca supe si realmente era por ese error, si fue algo pasajero o qué. Simplemente desearte suerte porque parece difícil encontrar lo que causa el error e influyen muchos factores.