Este artículo es, más bien, de una serie de "notas de anfitriona". Bueno, un poco más sobre experiencias personales y gubias.
Si tiene que lidiar con sitios de WordPress que tienen instalado el complemento de almacenamiento en caché de WP Super Cache, entonces el artículo puede serle útil. De lo contrario, esto es solo una historia corta.
En resumen, el comienzo de la historia es esta: había un sitio. Noticias e información temáticas. Hecho por un asistente desconocido en CMS WordPress. Y hecho exactamente como estaba permitido en ese momento por los medios de su dueño. Con el tiempo, el sitio ganó popularidad, el número de visitantes creció. El sitio en sí "ganó" en publicidad. Es decir Cuantos más visitantes, mejor. En algún momento, durante las cargas máximas, el sitio comenzó a aparecer: las páginas se cargaban lentamente y todo eso. Pero, por supuesto, hasta que la polla picoteó, nadie realmente se movió. El gallo apareció en el momento en que se suponía que el sitio cubría algún evento que atrajo la atención del público. Los visitantes entraron corriendo, el sitio se cayó y todos los ingresos estimados se derritieron ante nuestros ojos. Debido a las circunstancias, tuve que actuar como resucitador. Escribí
un artículo sobre esto entonces. Mi decisión fue espeluznante (no repita), pero el objetivo principal se cumplió: los sueños se salvaron. Mayormente
Por supuesto, nadie estaba interesado en repetir una situación similar y trabajó en el sitio. En primer lugar, descubrieron las razones de la caída y la alta carga en el servidor. Eran comunes: la falta de un sitio de almacenamiento en caché como tal y un mecanismo mal implementado para registrar y mostrar el número de vistas de artículos. Este último creó una carga decente: con cada solicitud de la página del artículo, tomaba de la base de datos el número de visitas de este artículo, lo mostraba y luego agregaba uno y lo volvía a escribir en la base de datos. Al mismo tiempo, la tabla
wp_postmeta con metadatos se usó para el almacenamiento (como parece llamarse en WP). En el que la masa se almacenaba completamente irrelevante para las vistas contables de la información y que era muy grande.
El problema de almacenamiento en caché se resolvió simplemente: en un entorno silencioso, el complemento WP Super Cache se instaló normalmente. Lo que, si recuerdo bien, me aconsejó que hiciera en lugar de la misteriosa muleta que construí en los comentarios sobre ese artículo mío. Honestamente, entonces y ahora navegaba mal en el ecosistema de WordPress y, por lo tanto, apareció esa muleta. El complemento de almacenamiento en caché se instaló y configuró por personas que ya conocían, y se levantó de inmediato. Por lo tanto, se resolvió el problema de almacenamiento en caché. Por qué se eligió este complemento, no estoy seguro. Según tengo entendido, este es uno de los complementos más populares de este tipo para WP.
Dadas las opiniones, actuaron de manera algo diferente. Está claro que el mecanismo original tuvo que ser abandonado. No quería negarme a tener en cuenta las opiniones en sí mismas: al menos un bloque que mostraba "los artículos más populares de la semana" estaba vinculado a él. Todos los complementos para grabar vistas, incluso si eran "amigos" con el complemento de almacenamiento en caché, resultaron ser muy voraces y, con mayor frecuencia, implementaron el mismo mecanismo para escribir y extraer datos de wp_postmeta. Para un sitio pequeño, esto es bastante adecuado. Para un sitio con tasas máximas de asistencia bastante sólidas, ya no: demasiado glotón para una función tan pequeña. Luego, por cierto, presenté hosting pagado y no utilizado en los años venideros. La más fácil y barata. Las responsabilidades de almacenar, registrar y devolver datos sobre las vistas fueron acumuladas en él. Todo es asíncrono, es decir. incluso si cae, el sitio principal continuará mostrando silenciosamente artículos, anuncios y todo lo que debería mostrar. El almacenamiento en línea de los datos de visualización se asignó a Redis y el almacenamiento a largo plazo a MySQL. Por lo tanto, está girando, realmente no pregunta, y consume 1-2% de la carga máxima permitida en ese alojamiento.
Y así, pasa mucho tiempo. Una y otra vez una vieja historia. Un tráfico bastante potente va al sitio y el sitio comienza a caer. Y nuevamente, soy el único especialista condicional despierto en el área. Por supuesto, estoy sorprendido por la repetición de eventos. Mi primer pensamiento es que alguien apagó accidentalmente el almacenamiento en caché. Pero no, en el código fuente de la página del sitio que me da el servidor que cae, veo signos de que funciona un complemento de almacenamiento en caché. Todo debería estar bien. Pero en el panel de control del servidor, veo que no queda RAM, la cantidad de consultas a la base de datos es increíble y todo está mal. En primer lugar, abro la página con la descripción del complemento, rápidamente paso por sus ojos, no encuentro nada y dejo esta actividad. El siguiente paso es ver las estadísticas. Veo que el flujo de tráfico principal está llegando al sitio desde Yandex.Zen. Y la solicitud que lleva al usuario al sitio se ve así:
https://example.com ? utm_referrer = https:% 2F% 2Fzen.yandex.com
Es decir Yandex.Zen agrega su etiqueta utm a la dirección. Dado que el servidor ya está completamente acostado y me da solo 500, por alguna razón no puedo verificar claramente la teoría de que las páginas con tal "ponderación" no estén en caché. Por lo tanto, nace otra "muleta" (se reemplazó posteriormente): se agrega una redirección a .htaccess, que convierte la solicitud con etiquetas utm en una solicitud sin ellas antes de que WordPress y todos sus complementos potentes entren en juego. La máquina se reinicia y, voila, todo funciona: el sitio se carga rápidamente, el servidor se mueve silenciosamente a bajas velocidades. Como no pasó nada.
Luego me relajé y subí tranquilamente mirando la configuración del plugin de almacenamiento en caché. En primer lugar, la casilla de verificación "No almacenar en caché las páginas con parámetros GET", que está allí. Todo está bien, ella no lo vale. Además, como lo mostró el experimento, el complemento hace frente al almacenamiento en caché de consultas con cualquier conjunto de parámetros arbitrarios. Si no se trata de etiquetas utm (de hecho, solo redirigí las solicitudes de cierto tipo y no corté todas las etiquetas utm).
Aquí cuidadosamente (usando CTRL + F) miré la página del complemento. Y encontré allí en las preguntas frecuentes el glorioso párrafo "¿Cómo debo usar mejor las herramientas de seguimiento utm_source en Google Analytics con este complemento?". Está claro que durante el primer examen superficial, lo ignoré con seguridad: parece que no hay nada que ver con el problema. Al mismo tiempo, por cierto, no es tan informativo y no ofrece ninguna solución específica.
La única conclusión útil posible en el artículo: si tiene un sitio WP con el complemento WP Super Cache, compruebe lo que hace (o no), si envía una solicitud con los parámetros “? Utm_referrer = https:% 2F% 2Fzen. yandex.com ", etc. No estoy seguro de que al instalar este complemento, todos lean sus preguntas frecuentes con tanto cuidado. La implementación específica, aparentemente, permanece con los propietarios del sitio: cuando vi por última vez la actualización de este complemento, no vi ningún cambio con respecto a su extraña reacción a las etiquetas utm.
Pero la historia habría sido incompleta (y no lo habría contado) si no hubiera habido otra confirmación de la ley de Murphy. Mientras mantuvimos correspondencia tranquila con el propietario del sitio y vimos cómo el sitio funcionó en silencio durante aproximadamente una hora ... el sitio cayó. Inesperadamente y finalmente. No hay acceso al panel de control del servidor, FTP, SSH y todo lo demás no funciona. Nada funciona Si antes de eso, mi presión aumentó ligeramente al resolver el problema que vomitaron J. Zen y el plugin de almacenamiento en caché (después de todo, es un placer especial comprender rápidamente y solucionar algo sin problemas), entonces me ocurrió un ataque de mini-pánico. Y solo la vaga sensación de que un par de líneas en .htaccess no puede matar todo una hora después de hacer estas líneas no permitió que el "mini" se convirtiera en algo más completo. En general, después de un par de minutos de intercambiar mensajes sorprendidos, ingresamos a la cuenta personal del proveedor de alojamiento donde vive el servidor. Y allí, en las entradas, encontramos una advertencia sobre "trabajo técnico de X a Y en MSC". Lo más interesante es que en la oficina de correos, no importa cómo buscamos, no encontramos ningún mensaje del proveedor sobre estos trabajos. El boleto tenía al menos un día de antigüedad. Antes de esto, tales mensajes llegaban al correo, y generalmente nadie mira los tickets del servicio de soporte (y la propia oficina del proveedor de alojamiento) generalmente sin ninguna necesidad especial. Por lo tanto, lo que sucedió fue una gran sorpresa. Después de eso, regañamos los ojos del hoster, nos reímos, esperamos hasta que todo funcionó y nos fuimos a dormir.
Aquí hay una historia.