Una mirada a la pila moderna de servidores de WordPress

¿Recuerdas cuando podías ejecutar un sitio web de WordPress "rápido" con solo un servidor Apache y PHP? ¡Sí, esos eran los días! Las cosas eran mucho menos complicadas en ese entonces.

¡Ahora, todo tiene que cargarse a la velocidad del rayo! Los visitantes no tienen las mismas expectativas sobre los tiempos de carga que solían tener. Un sitio web lento puede tener serias implicaciones para usted o su cliente.

Lectura adicional en SmashingMag:

• Permisos y propiedad adecuados del sistema de archivos de WordPress
• Mover un sitio web de WordPress sin problemas
• Cómo desarrollar WordPress localmente con MAMP
• Métodos de almacenamiento en caché de bricolaje con WordPress

En consecuencia, la pila de servidores de WordPress ha tenido que evolucionar a lo largo de los años para mantenerse al día con esta necesidad de velocidad. Como parte de esta evolución, se han tenido que añadir algunas marchas a su motor. Algunos de los engranajes más antiguos también han tenido que cambiar.

El resultado es que la pila del servidor de WordPress se ve bastante diferente hoy que hace unos años. Para entenderlo mejor, vamos a explorar esta nueva pila en detalle. Verá cómo encajan las distintas piezas para hacer que un sitio web de WordPress sea rápido.

Visión de conjunto

Antes de sumergirnos, alejémonos y observemos el panorama general. ¿Cómo se ve esta nueva pila de servidores de WordPress? Bueno, aquí está la respuesta:

El diagrama anterior ofrece una buena descripción general de cómo se ve la pila de servidores de WordPress moderna. A un alto nivel, podemos dividir lo que está pasando en tres áreas:

• el ciclo de solicitud-respuesta entre el navegador y WordPress;
• WordPress (que es un script que ejecuta el tiempo de ejecución de PHP);
• el ciclo de consulta-resultado entre WordPress y la base de datos MySQL.

El papel de la pila de servidores de WordPress moderna es optimizar estas tres áreas. Estas optimizaciones son las que hacen que todo se cargue más rápido. Y lo mejor es que hay varias formas de hacerlo. (¡Hurra!)

En la mayoría de los casos, estas optimizaciones implican la instalación de nuevos servicios en su servidor. A veces, estos servicios necesitarán la ayuda de un complemento para interactuar con WordPress. También habrá momentos en los que puede salirse con la suya simplemente instalando un complemento. Verás muchas opciones diferentes a lo largo de este artículo.

El ciclo de solicitud-respuesta

Todo comienza con el navegador. Supongamos que desea ver la página de inicio de modern.wordpress-stack.org . Su navegador comenzará enviando una solicitud HTTP al servidor web que lo aloja. En el otro extremo, el servidor web tomará su solicitud y la convertirá en una respuesta HTTP.

Esta primera respuesta siempre debe ser el contenido HTML de la página de inicio de modern.wordpress-stack.org (a menos que haya un error). Sin embargo, el trabajo de su navegador no ha terminado. No, esa página de inicio todavía necesita más archivos, los más comunes son archivos CSS, JavaScript e imágenes.

Entonces, el navegador enviará solicitudes para esos archivos. El servidor web responderá con los archivos solicitados (nuevamente, siempre que no haya errores). Este ciclo continuará hasta que el navegador tenga suficiente información para mostrar la página de inicio. Cuanto más rápido ocurra este ciclo, más rápido parecerá que se carga el sitio web.

Ahora, esta es una simplificación obvia, pero así es como funcionan las cosas para la mayoría de los sitios web de WordPress.

Optimización del ciclo de solicitud-respuesta

Muy bien, esto nos lleva a la pregunta obvia: ¿Cómo hacemos que un servidor web realice este ciclo más rápido? Esta es una gran pregunta y es parte de la razón por la cual existe la pila de servidores de WordPress moderna.

La pila existe porque no se puede simplemente hacer que un servidor web sea más rápido. Un servidor web también es un despachador. Puede recibir una solicitud y simplemente reenviarla a otros servicios.

Estos otros servicios suelen ser el cuello de botella de este ciclo de solicitud y respuesta. Con WordPress, este cuello de botella es PHP, por lo que optimizar el ciclo de solicitud y respuesta se reduce a dos cosas. Queremos que el servidor web:

• recibir la menor cantidad de solicitudes posible,
• reenviar la menor cantidad posible de solicitudes a PHP.

La pila de servidores de WordPress moderna se centra en este último. Quiere reenviar la menor cantidad posible de solicitudes a PHP. Ese será el objetivo principal para optimizar la pila.

Nos enfocamos en el segundo objetivo porque la pila no puede hacer mucho sobre el primero; no tiene un impacto directo en él. El segundo lo aborda la configuración del servidor web o las modernas técnicas de desarrollo.

Pila de elementos para el ciclo de solicitud-respuesta

Entonces, ¿cuáles son los elementos de la pila que nos ayudarán a reducir las solicitudes enviadas a PHP? Bueno, dos elementos de la pila en particular nos ayudarán a lograr ese objetivo: el servidor web y el caché HTTP.

Servidor web

Ya hemos estado hablando un poco acerca de los servidores web. Hay tres grandes jugadores en el espacio del servidor web:

• apache
• Servicios de información de Internet (IIS)
• nginx

Juntos, representan más del 90% de la cuota de mercado de los servidores web en Internet. Nos vamos a centrar en Apache y nginx. Si bien IIS se puede usar para ejecutar WordPress, no es común porque solo está disponible para Windows y la mayoría de los servidores de WordPress usan Linux.

Esto nos deja con Apache y nginx. Durante toda la vida de WordPress, Apache ha sido el servidor web recomendado. Teníamos la pila LAMP (Linux, Apache, MySQL y PHP), que ejecutaba WordPress tanto en la computadora como en el servidor.

Pero detrás de escena, las cosas estaban cambiando. Había un nuevo jugador en la ciudad y su nombre era nginx. Automattic y WordPress.com lo han estado usando desde 2008. Es el servidor web que ejecuta el mayor porcentaje de sitios web de alto tráfico (muchos de los cuales ejecutan WordPress). Es por eso que muchas empresas de alojamiento de alta gama y las principales agencias de WordPress lo usan como su servidor web.

No es que Apache sea un mal servidor web. Hay expertos en Apache que pueden hacer que funcione muy bien con mucho tráfico. Simplemente no funciona tan bien fuera de la caja o con la configuración estándar de WordPress.

Mientras tanto, el único propósito de nginx es manejar una gran cantidad de tráfico. Es por eso que Igor Sysoev comenzó el proyecto cuando trabajaba en Rambler.

Una de las razones por las que nginx maneja mejor más tráfico es que usa FastCGI para comunicarse con PHP. ¿Qué es FastCGI? Es un protocolo que permite que PHP se ejecute como un servicio separado del servidor web.

Apache no hace esto por defecto. Cada vez que el servidor web recibe una solicitud, debe iniciar un proceso de tiempo de ejecución de PHP, incluso para imágenes, JavaScript y CSS. Esto reduce la cantidad de solicitudes que el servidor puede manejar y la rapidez con que puede manejarlas.

Esto va en contra de uno de los objetivos de la pila de servidores de WordPress moderna, que vimos anteriormente. La pila debe mantener el tiempo del ciclo de solicitud-respuesta lo más bajo posible. Cargar PHP para cada solicitud, incluso cuando no lo necesita, va en contra de este objetivo. Entonces, si usa Apache, busque FastCGI.

HTTP/2 es otra característica importante del servidor web que debe conocer. Es la próxima versión de HTTP, el protocolo que impulsa todo nuestro ciclo de solicitud y respuesta.

Antes de la llegada de HTTP/2, un navegador solo podía tener seis conexiones al servidor web. Y cada conexión solo podía manejar una solicitud a la vez. Entonces, en la práctica, un ciclo de solicitud-respuesta se limitó a seis solicitudes por ciclo.

Ese es un verdadero problema. La mayoría de los sitios web tienen docenas de solicitudes en su ciclo. Los desarrolladores y administradores de sistemas encontraron formas inteligentes de sortear esta limitación.

Una de las soluciones más conocidas es la práctica de combinar archivos CSS y JavaScript. En un escenario ideal, esto reduciría la cantidad total de solicitudes de archivos CSS y JavaScript a dos: una para JavaScript y otra para CSS.

Esto no es necesario con HTTP/2. HTTP/2 permite un número ilimitado de solicitudes por conexión. Esto permite que todas las solicitudes adicionales después de la respuesta HTML inicial ocurran al mismo tiempo.

Esto tiene enormes implicaciones de rendimiento. Gran parte del trabajo de optimización de la pila del servidor se centra en el ciclo de solicitud-respuesta. Al reducir la cantidad de ciclos a solo unos pocos, HTTP/2 ha hecho una gran cantidad de trabajo para nosotros.

caché HTTP

La parte más importante de la pila de servidores de WordPress moderna es la caché HTTP. En el mundo de WordPress, también llamamos a esta página almacenamiento en caché. El propósito de la caché HTTP es almacenar en caché las respuestas a las solicitudes. ¿Qué significa esto?

Bueno, volvamos a nuestro ejemplo anterior. El navegador envía una solicitud para la página de inicio de modern.wordpress-stack.org , y el servidor web recibe esa solicitud y la reenvía a PHP.

El problema con este escenario es que el servidor web es tonto. Siempre reenviará todas las solicitudes que reciba a PHP, independientemente de si la mayoría de las solicitudes generarían la misma respuesta.

Esto es exactamente lo que sucede cuando los visitantes no han iniciado sesión. Para el servidor web, todas son solicitudes diferentes, pero no importa. Los reenviará todos a PHP, que generará la misma respuesta para todos ellos.

¡Eso es terrible! Como vimos anteriormente, PHP es el verdadero cuello de botella de nuestro ciclo de solicitud y respuesta. Su navegador no puede enviar sus solicitudes de seguimiento hasta que reciba la respuesta inicial de la página de inicio. No podemos hacer que el servidor web reenvíe todo a PHP de forma predeterminada.

Ahí es donde entra en juego el caché HTTP. Se encuentra entre el servidor web y PHP. Su trabajo es verificar cada solicitud que recibe el servidor web y buscar una respuesta en caché. Si no hay ninguno, reenviará la solicitud a PHP y luego almacenará en caché la respuesta que genera PHP.

Esto reduce drásticamente el tiempo del ciclo de solicitud-respuesta, lo que hace que el sitio web se cargue más rápido. También permite que el servidor web maneje más solicitudes simultáneas sin explotar.

Los diferentes sabores de la caché HTTP

En este punto, debería preguntarse: "¿Cómo puedo tener este bebé en mi servidor lo antes posible?" La buena noticia es que instalar un caché HTTP en un servidor de WordPress es bastante fácil. Es el componente con la gama más amplia de opciones.

Instalar un complemento de almacenamiento en caché de páginas

La forma más fácil es instalar un complemento de almacenamiento en caché de páginas. Tienes algunas opciones para elegir:

• Batcaché
• hipercaché
• Habilitador de caché
• Cohete WP
• Súper caché de WP
• Caché total W3

Todos menos WP Rocket están disponibles como complementos gratuitos en el directorio de WordPress. Por lo tanto, puede instalar uno y probarlo de inmediato. Dicho esto, de los cuatro complementos, el mejor es WP Rocket. Si bien es un complemento pago, hace mucho más que solo crear un caché HTTP. Estos otros beneficios magnifican el trabajo que está haciendo la caché HTTP.

¿Cómo funciona un complemento de almacenamiento en caché de páginas?

Todos estos complementos aprovechan un complemento que WordPress ha puesto a disposición para el almacenamiento en caché. Este complemento de almacenamiento en caché permite que los complementos creen un sistema de caché HTTP dentro de WordPress. El drop-in de almacenamiento en caché necesita dos cosas para funcionar.

Primero, el archivo desplegable advanced-cache.php debe estar en la carpeta wp-content . Ese es el archivo real. Pero a diferencia de la mayoría de los complementos de WordPress, este no se activa de forma predeterminada. WordPress también necesita que la constante WP_CACHE sea true para cargar el drop-in. En la mayoría de los casos, configuraría eso en wp-config.php .

El diagrama anterior muestra lo que sucede cuando habilita el complemento con un complemento de almacenamiento en caché. WordPress carga el drop-in en wp-settings.php durante su proceso de carga. Esto es lo suficientemente temprano en el proceso que WordPress aún no ha hecho nada que requiera mucho tiempo.

El complemento de almacenamiento en caché verificará si ya ha almacenado en caché la respuesta a la solicitud. Si es así, devolverá esa respuesta almacenada en caché. Si no lo ha hecho, activará el almacenamiento en búfer de salida de PHP y WordPress continuará cargándose.

Ahora, el almacenamiento en búfer de salida es un sistema interesante. Lo que hace es capturar toda la salida de un script PHP en una variable de cadena hasta que sucede una de dos cosas:

• le dices a PHP que deje de almacenar en búfer su salida usando una de las funciones integradas,
• el script PHP finaliza y necesita devolver una respuesta al navegador.

El complemento de almacenamiento en caché cuenta con el último escenario. Quiere que WordPress haga lo suyo y luego almacene en caché todo el resultado antes de que PHP lo envíe de vuelta al navegador. Puedes ver el proceso en el siguiente diagrama.

Haga que el servidor web lo haga

La siguiente opción es agregar un caché HTTP a nivel del servidor web. La forma en que funciona es que el servidor web almacenará en caché todas las respuestas a las solicitudes que se reenvían a PHP. Esta solución es mejor que un complemento de almacenamiento en caché porque no necesita tocar PHP en absoluto.

El diagrama anterior ofrece una descripción general de lo que sucede en el servidor web. El servidor web recibe una solicitud y verifica con el caché HTTP. Si ya se ha almacenado en caché una respuesta, la caché HTTP la devolverá.

De lo contrario, reenviará la solicitud al módulo PHP (generalmente FastCGI). Pasará la solicitud a WordPress para que pueda generar una respuesta. El módulo de caché HTTP luego almacenará en caché esa respuesta en el camino de regreso.

Tanto Apache como nginx vienen con la capacidad de agregar un sistema de caché HTTP. El nginx está integrado. El de Apache es un módulo separado que debe agregar a su instalación de Apache.

No hay mucha información sobre cómo usar el módulo Apache con PHP o WordPress. Eso podría deberse a que no es popular entre la gente de Apache, o quizás porque tiene algunos problemas. Hay al menos un problema de larga data que todavía está abierto.

Mientras tanto, el sistema de caché HTTP de nginx es sólido y está bien documentado. Puede usarlo como un caché HTTP normal o como un micro-caché más pequeño pero efectivo. Es solo una razón más por la que nginx es el servidor web preferido hoy en día.

Agregar barniz a la pila

¿Qué es el barniz? Es un servidor de caché HTTP dedicado (o, como a sus desarrolladores les gusta llamarlo, acelerador HTTP). La mayoría de los sitios web de alto tráfico y las empresas de alojamiento premium lo utilizan como su solución de caché HTTP.

Lo usan porque es poderoso y ofrece la mayor flexibilidad. Varnish tiene su propio lenguaje de configuración, llamado VCL. Le permite controlar cada elemento del proceso de almacenamiento en caché. Varnish también viene con muchas herramientas para analizar qué está haciendo el caché y cómo se está desempeñando.

Estas son las principales diferencias entre usarlo y simplemente usar el caché HTTP del servidor web incorporado. El caché HTTP del servidor web incorporado es de gran rendimiento pero también bastante básico. No tienes mucho control más allá de unas pocas opciones de configuración.

Sin embargo, este poder y flexibilidad tienen un precio. Varnish es también la opción de caché HTTP más complicada. No hace nada más que almacenar en caché las respuestas HTTP. No maneja la terminación SSL, que la mayoría de los desarrolladores de WordPress quieren (o deberían querer). Esto significa que nuestra moderna pila de servidores de WordPress será más compleja cuando la usemos.

El diagrama anterior ilustra esta complejidad adicional. Ahora tenemos dos componentes más en nuestra pila de servidores de WordPress: Varnish y un proxy inverso.

El proxy inverso está ahí para superar la limitación que tiene Varnish con SSL. Se sienta frente a Varnish y descifra las solicitudes que recibe nuestro servidor. También puede llamar a este tipo de proxy inverso un proxy de terminación SSL. Luego, el proxy envía estas solicitudes descifradas a Varnish para que las procese.

Una vez que una solicitud llega a Varnish, los archivos de configuración de VCL se activan. Son el cerebro de Varnish. Por ejemplo, le dicen cómo:

• analizar, limpiar y modificar las solicitudes entrantes;
• busque una respuesta en caché;
• analizar, limpiar y modificar las respuestas de retorno de WordPress;
• almacenar en caché estas respuestas de retorno;
• manejar una solicitud para eliminar una o más respuestas del caché.

Este último es especialmente importante. Si se lo deja solo, Varnish no tiene forma de saber cuándo WordPress quiere eliminar una página del caché. Entonces, de manera predeterminada, si realiza cambios en una publicación y la actualiza, los visitantes seguirán viendo la misma página en caché. Afortunadamente para nosotros, existe un complemento que elimina páginas del caché de Varnish.

WordPress

Muy bien, nuestra solicitud de la página de inicio de modern.wordpress-stack.org ha llegado a WordPress. Pasó por el ciclo de solicitud-respuesta que acabamos de cubrir. El caché HTTP hizo todo lo posible para encontrar una respuesta HTTP para devolver.

Pero no hubo una respuesta HTTP en caché para enviar al navegador. En ese momento, el caché HTTP no tenía otra opción. Tenía que reenviar la solicitud HTTP a WordPress.

Todo está en manos de WordPress ahora. WordPress tiene que convertir nuestra solicitud HTTP en una respuesta HTTP y enviarla de vuelta a la memoria caché HTTP. Como vimos anteriormente, este es el principal cuello de botella de toda nuestra pila moderna de servidores de WordPress.

La causa de este cuello de botella es doble. WordPress tiene mucho código PHP para ejecutar. Esto lleva mucho tiempo, y cuanto más lento es PHP para hacerlo, más tiempo lleva.

El otro cuello de botella son las consultas a la base de datos que debe realizar WordPress. Las consultas a bases de datos son operaciones costosas. Cuantos más hay, más lento se vuelve WordPress. Este será el enfoque de la última sección sobre el ciclo de consulta-resultado.

Optimización del tiempo de ejecución de PHP

Volvamos a PHP. En este momento, WordPress tiene un requisito mínimo de PHP 5.2. ¡Esta versión de PHP tiene casi 10 años! (El equipo de PHP dejó de admitirlo en 2011).

El equipo de PHP no ha estado inactivo todos estos años. Se han realizado numerosas mejoras de rendimiento, especialmente en los últimos años. Veamos qué puedes hacer para optimizarlo hoy en día.

Utilice la última versión de PHP

Lo más fácil que puede hacer es actualizar su versión de PHP. Las versiones 5.4, 5.5 y 5.6 vieron mejoras de rendimiento. La mayor mejora fue de 5,3 a 5,4. Cambiar a él aumentó el rendimiento de WordPress en una cantidad decente.

Instalar almacenamiento en caché de código de operación

El almacenamiento en caché de código de operación es otra forma de acelerar PHP. Como lenguaje de secuencias de comandos del lado del servidor, PHP tiene un gran defecto: necesita compilar una secuencia de comandos PHP cada vez que lo ejecuta.

La solución a este problema es almacenar en caché el código PHP compilado. De esa forma, PHP no tiene que compilarlo cada vez que lo ejecuta. Este es el trabajo del caché de código de operación.

Antes de PHP 5.5, PHP no venía incluido con un caché de código de operación. Tuviste que instalarlo tú mismo en el servidor. Esta es otra razón por la que es mejor usar una versión más reciente de PHP.

Cambie a un compilador de próxima generación

Lo último que puede hacer es cambiar a uno de los dos compiladores de próxima generación: HHVM de Facebook o PHP 7, la última versión de PHP. (¿Por qué PHP 7? Es una larga historia).

Facebook y el equipo de PHP crearon estos dos compiladores desde cero. Querían aprovechar estrategias de compilación más modernas. HHVM usa compilación justo a tiempo, mientras que PHP 7 usa compilación anticipada. Ambos ofrecen increíbles mejoras de rendimiento sobre el buen PHP 5.

HHVM fue el primero en llegar a escena hace unos años. Muchos hosts de primer nivel han tenido mucho éxito con él, ofreciéndolo como su principal compilador de PHP.

Sin embargo, vale la pena enfatizar que HHVM no es un compilador oficial de PHP. No es 100% compatible con PHP. La razón es que HHVM no solo está diseñado para soportar PHP; también es un compilador para el lenguaje de programación Hack de Facebook.

PHP 7 es un compilador PHP oficial. No ha existido por mucho tiempo. El equipo de PHP lo lanzó en diciembre de 2015. Esto no ha impedido que algunas empresas de alojamiento de WordPress ya lo admitan.

¡La buena noticia es que WordPress en sí mismo es 100% compatible con ambos compiladores! La mala noticia es que no todos los complementos y temas lo son, porque la versión mínima de PHP para WordPress sigue siendo 5.2.

Nada obliga a los autores a hacer que sus complementos o temas funcionen con estos compiladores. Entonces, no puedes ir con uno de ellos. Su pila siempre debe volver a PHP 5.

Ciclo Consulta-Resultado

En este punto, el tiempo de ejecución de PHP está revisando todos los archivos PHP de WordPress y ejecutándolos. Sin embargo, estos archivos PHP de WordPress no contienen ningún dato. Solo contienen el código de WordPress.

El problema es que WordPress almacena todos sus datos en una base de datos MySQL. Entonces, para llegar a él, el tiempo de ejecución de PHP necesita consultar esa base de datos. El servidor MySQL devuelve el resultado de esa consulta, y el tiempo de ejecución de PHP continúa ejecutando los archivos PHP de WordPress… bueno, eso es, hasta que necesita datos nuevamente.

Este ir y venir puede ocurrir desde unas pocas docenas de veces hasta unos cientos de veces. (¡Es posible que desee hablar con su desarrollador si es lo último!) Es por eso que es un cuello de botella importante.

Optimización del ciclo de consulta-resultado

El objetivo de optimización aquí es acelerar el tiempo de ejecución de los archivos de WordPress por PHP. Aquí es donde las consultas a la base de datos son problemáticas. Tienden a tomar más tiempo que simplemente ejecutar código PHP simple (a menos que su código esté haciendo algo escandaloso).

La forma obvia de solucionar este problema es reducir la cantidad de consultas que WordPress necesita realizar. ¡Y eso siempre vale la pena! Pero no es algo con lo que la moderna pila de servidores de WordPress pueda ayudar.

Es posible que no podamos reducir la cantidad de consultas que hace WordPress, pero tampoco nos quedamos sin opciones. Todavía hay dos formas en que la pila puede ayudarnos a optimizar el ciclo de consulta-resultado. Puede reducir la cantidad de consultas realizadas a la base de datos en primer lugar. Y para aquellas consultas que llegan a la base de datos, puede disminuir el tiempo que lleva ejecutarlas.

Estas dos opciones están destinadas a hacer lo mismo: hacer que PHP espere lo menos posible los resultados de la base de datos, lo que hará que WordPress sea más rápido.

Pila de elementos para el ciclo de consulta-resultado

Veamos los diferentes elementos de la pila involucrados en el ciclo de consulta-resultado. Esta parte de la pila es menos compleja. Pero aún involucra más de un componente, a saber, el servidor de base de datos MySQL y el caché de objetos.

Servidor de base de datos MySQL

Hace unos años, un servidor de base de datos MySQL significaba lo mismo para todos. Era un servidor con el servidor MySQL instalado. Pero las cosas han cambiado mucho en los últimos años.

Varios grupos no estaban contentos con la forma en que Oracle administraba el proyecto MySQL. Por lo tanto, cada grupo lo bifurcó y creó su propia versión en la que podría "incluir" en su lugar. El resultado es que ahora hay varios servidores de bases de datos MySQL.

El nuevo servidor MySQL "oficial" es el servidor MariaDB. Es la versión desarrollada por la comunidad del servidor MySQL. La comunidad planea mantener una compatibilidad total con el proyecto del servidor MySQL.

Otra alternativa popular a MySQL es el servidor Percona. A diferencia de MariaDB, Percona es más una rama de MySQL. Sus desarrolladores no están en contra del proyecto MySQL en sí mismo; solo quieren concentrarse en mejorar el rendimiento de MySQL. Posteriormente, el equipo de MariaDB fusionó algunas de estas mejoras de rendimiento en el proyecto MariaDB.

Al final del día, puedes elegir el que prefieras. No hay diferencia en el rendimiento entre un servidor Percona y un servidor MariaDB (para la mayoría de nosotros de todos modos). Ambos funcionan mejor que MySQL. Sin embargo, Percona mantiene una mayor compatibilidad con el proyecto Oracle.

Lo que sí afecta el rendimiento es el motor de almacenamiento que utiliza la base de datos de WordPress. El motor de almacenamiento controla cómo el servidor de la base de datos administra los datos que almacena. También puede configurar un motor de almacenamiento diferente por tabla de base de datos; no tiene que usar el mismo para toda la base de datos.

Un servidor de base de datos tiene varios motores de almacenamiento. No los vamos a mirar todos. Solo dos nos interesan: InnoDB y MyISAM.

De forma predeterminada, WordPress utiliza el motor de base de datos MySQL predeterminado. Antes de MySQL 5.5, ese motor era MyISAM. Si ejecuta un sitio web pequeño de WordPress, entonces MyISAM está bien. MyISAM se encuentra con problemas de rendimiento una vez que un sitio web crece en tamaño. En ese momento, InnoDB es la única opción para un motor de base de datos.

El único problema con InnoDB es que requiere algunos ajustes para funcionar de la mejor manera. Si está ejecutando un servidor de base de datos grande, es posible que deba ajustar las cosas. Afortunadamente para nosotros, hay una herramienta para ayudar con eso.

MySQLTuner es un pequeño script que analiza su servidor de base de datos. Generará un informe y le dará recomendaciones de ajuste.

Caché de objetos

La mayor parte del trabajo de optimización del ciclo de consulta-resultado recae en la caché de objetos. El trabajo de la caché de objetos es almacenar datos cuya obtención o generación requiere mucho tiempo. Como puede suponer, las consultas de la base de datos son un candidato perfecto.

WordPress usa mucho el caché de objetos. Digamos que usa get_option para obtener una opción de la base de datos. WordPress solo consultará la base de datos para esa opción una vez. No volverá a consultarlo la próxima vez que alguien lo necesite.

En cambio, WordPress obtendrá el resultado de la consulta del caché de objetos. Este es un paso proactivo que toma WordPress para reducir la cantidad de consultas a la base de datos que necesita realizar. Pero no es una solución infalible.

Si bien WordPress hará todo lo posible para aprovechar el caché de objetos, un complemento o tema no tiene por qué hacerlo. Si un complemento o tema realiza muchas consultas a la base de datos y no almacena en caché los resultados, la pila no puede hacer nada al respecto.

En tales casos, la mayoría de las consultas a la base de datos provendrán del propio WordPress. Por lo tanto, obtendrá un gran beneficio del uso integrado de WordPress del caché de objetos. Es por eso que es un elemento importante de la pila de servidores de WordPress moderna.

Ahora, un problema con el caché de objetos es que no conserva los datos que almacena de manera predeterminada. Simplemente almacena datos en la memoria mientras PHP ejecuta todos los archivos de WordPress. Pero una vez que finaliza el proceso de PHP, se borran todos los datos almacenados en la memoria.

Esto no es ideal en absoluto. Una caché de objetos puede permanecer válida durante mucho tiempo, por lo que no desea limitarla a una sola solicitud. La solución es utilizar una caché de objetos persistente .

Un caché de objetos persistentes a menudo viene en forma de complemento. Ese complemento haría uso del complemento object-cache.php para hacer su trabajo. Este complemento permite a los autores de complementos cambiar el comportamiento predeterminado de la caché de objetos.

Luego, los complementos conectan el caché de objetos a un almacén de datos persistente. Lo hacen reemplazando la funcionalidad de buscar y guardar de la memoria caché de objetos predeterminada. En lugar de guardar y recuperar datos en la memoria, la memoria caché de objetos lo hace desde ese almacén.

Complementos de caché de objetos persistentes

Hoy en día, hay dos opciones populares de almacenamiento de datos para el almacenamiento en caché de objetos persistentes:

• Memcached (complemento)
• Redis (complemento)

Ambos almacenes de datos usan RAM para el almacenamiento, lo que los hace ultrarrápidos. De hecho, su rendimiento es comparable al de la memoria caché de objetos predeterminada.

El único problema es que no vienen preinstalados en los servidores. Y tampoco su extensión PHP (que es opcional con Redis). Debe instalar uno antes de poder usar el complemento de WordPress correspondiente.

¿Cuál deberías instalar? En la práctica, no hay mucha diferencia entre los dos para el almacenamiento en caché de objetos. En el pasado, la opción popular era Memcached. Esto ha cambiado en los últimos años. Redis ha agregado muchas funciones que lo han convertido en la opción preferida para el almacenamiento en caché de objetos.

Obtención de su propio servidor moderno de WordPress

Entonces, ¿cómo obtienes tu propio servidor? La forma obvia es obtener uno de una empresa de alojamiento de WordPress de primer nivel. Estas empresas quieren mantenerse a la vanguardia del negocio de alojamiento de WordPress, lo que las motiva a adoptar los últimos avances y tecnologías.

Pero, ¿y si quieres uno sin romper el banco? Hay un par de herramientas disponibles para cualquiera que prefiera hacerlo por sí mismo y pagar menos por el alojamiento. Mirémoslos.

DebOps para WordPress

DebOps para WordPress es una herramienta que construí para ayudar a cualquiera a construir un servidor de WordPress moderno. Su misión es hacer que la pila de servidores de WordPress moderna esté disponible para cualquier miembro de la comunidad. Es por eso que estoy tratando de que sea lo más fácil de usar posible. No necesita ningún conocimiento de administración de sistemas para usarlo.

DebOps para WordPress configura un servidor con lo siguiente:

• HHVM (hasta que PHP 7 se convierta en un repositorio oficial de Linux)
• MariaDB
• nginx
• redis
• Barniz

La herramienta hace más que configurar un servidor con las últimas tecnologías. También se encarga de proteger el servidor por usted. Esto es algo que la gente suele pasar por alto cuando administra su propio servidor.

EasyEngine

EasyEngine es una herramienta de línea de comandos diseñada para ayudarlo a configurar un sitio web de WordPress en un servidor. Lo mejor de EasyEngine es su flexibilidad: puede usarlo para configurar casi cualquier combinación de tecnologías de servidor que hayamos visto hasta ahora.

Por ejemplo, le permite configurar un servidor con HHVM o PHP 7. Le permite elegir entre Memcached y Redis para su almacén de datos persistente. Y te permite instalar herramientas de administrador como phpMyAdmin.

También ofrece una gran cantidad de opciones cuando crea un sitio web de WordPress. Puede decirle que configure un sitio web con un caché HTTP usando un complemento o nginx. Toda esta flexibilidad es la razón por la cual EasyEngine es una herramienta tan popular.

Conducción

Trellis es una herramienta desarrollada por Roots. Al igual que DebOps, configura el servidor con un conjunto específico de tecnologías de servidor:

• MariaDB
• Memcaché
• nginx
• caché HTTP nginx (opcional)
• PHP 7

Una cosa que debe saber sobre Trellis es su relación con Bedrock, otra herramienta creada por Roots. Bedrock es un modelo para estructurar un sitio web de WordPress en torno a los principios de la "aplicación de doce factores".

El equipo de Roots creó Trellis para permitir que las personas configuren un servidor que utiliza sitios web de WordPress estructurados por Bedrock. No puedes usarlo con una instalación normal de WordPress, así que tenlo en cuenta.

Los tiempos han cambiado

Como puede ver, ¡un servidor de WordPress tiene muchas más partes móviles hoy en día! Pero esto no tiene por qué ser motivo de desesperación. No es tan malo como parece porque no siempre es necesario utilizar todas las piezas.

Es por eso que gran parte de este artículo analiza cómo estas partes funcionan juntas. El punto es empoderarte para que tomes tus propias decisiones. Use este conocimiento para decidir qué partes necesita usar y cuándo. De esta manera, usted también tendrá un sitio web de WordPress rápido.