PHP 8 y PHP 7 para mejorar el rendimiento y el WPO
Categoría:
Soporte y Ayuda, Sysadmin, WPO, Temas técnicos sobre webs
Fecha:
02/09/2021
A estas alturas no debería ser necesario explicar qué es PHP. El Hypertext Preprocessor es el lenguaje web interpretable del lado del servidor más utilizado, con una cuota de mercado aplastante, según las estadísticas públicas mostradas en W3Techs:
La tabla anterior puedes verla actualizada en esta URL: https://w3techs.com/technologies/overview/programming_language
Pero de estos porcentajes no solo debemos interpretar los números que vemos, sino también las gráficas de crecimiento o pérdida de cuota de mercado.
Mientras que PHP se mantiene e incluso sube un poco: https://w3techs.com/diagram/history_technology/pl-php
El segundo competidor, ASP.NET baja muy rápido: https://w3techs.com/diagram/history_technology/pl-aspnet
Bien es cierto que hay algunas tecnologías SSI (Server Side Rendering) que suben cuota de mercado bastante rápido, como Javascript o Ruby. Sin embargo, todavía están lejos de PHP.
En los últimos años PHP ha mejorado muchísimo en efectividad, consiguiendo un mejor rendimiento y un menor consumo de recursos.
Podemos decir que PHP 8 ha mejorado la eficiencia casi un 400% frente a PHP 5.6.
Recordemos que PHP 7.0 se publicó en 2015, pero no tuvo una fuerte implementación hasta 2016-2017. Es decir, poco a poco se fue dejando de usar PHP 5.6.
Con esto quiero decir que, en apenas 5 años de actualizaciones, PHP ha conseguido doblar e incluso triplicar el rendimiento y bajar el consumo de recursos.
Aunque el rendimiento y la eficiencia no ha sido la única mejora de PHP 7 y PHP 8 frente a PHP 5.6, en ciertos ambientes “no técnicos” ha sido la que más ha llamado la atención.
Como hemos comentado anteriormente, una de las cosas que más ha destacado en PHP a lo largo de estos años han sido las mejoras de rendimiento.
Para que veas a lo que me refiero, la siguiente gráfica representa unos benchmarks (pruebas) de rendimiento realizados en un Plan Inicio SSD de Raiola Networks con las distintas versiones de PHP desde la 7.0 hasta la 8.0.
Como se puede observar, desde la versión 7.0 hasta la versión 8.0 se dobla prácticamente la velocidad en la ejecución de operaciones con el intérprete PHP.
Pero hay más, ya que, si prestas atención a este otro gráfico, te darás cuenta de que desde la versión 5.1 de PHP se ha cuadruplicado el rendimiento:
Esto no quiere decir que tengamos que actualizar a una nueva versión de PHP siempre que esté disponible, simplemente nos recuerda que -al menos por WPO- es imprescindible no quedarse atrás.
Cuando sale una nueva versión de PHP normalmente ni los CMS ni los plugins son compatibles, ya que cambian código en el intérprete PHP y necesitamos que los desarrolladores los cambien en el código de sus aplicaciones para no tener problemas.
Por ejemplo, WordPress es compatible con PHP 8 desde la versión 5.6. Es decir, ha tardado 9 meses desde la salida de PHP 8 en ser compatible.
Sin embargo, en a fecha de 30 agosto de 2021, solo el 60% de los plugins del repositorio son compatibles con PHP8, por lo que todavía hay muchísimos plugins que no soportan esta versión de PHP y que, si los usáramos, no podríamos pasar de PHP 7.4 a PHP 8.
Profundizando más en el tema de los principales CMS del mercado trabajando con las nuevas versiones de PHP, nos encontramos que el núcleo de WordPress se adapta rápidamente a las nuevas versiones de PHP.
Recuerdo bastante bien cuando hace unos años WordPress empezó a funcionar con PHP 7.0. La velocidad conseguida al realizar este cambio fue brutal, y un consultor WPO como yo se acuerda de estas cosas.
Aunque con la versión 8.0 de PHP no se ha conseguido el mismo salto en lo que a velocidad de carga se refiere, podemos decir que sí ha mejorado bastante. Esto resalta más si comparamos PHP 7.0 con PHP 8, pasando por todas las ramas PHP 7.X.
Como hemos mencionado anteriormente, el núcleo de WP se adapta rápidamente a las nuevas versiones de PHP, pero cabe destacar que los desarrolladores de los plugins suelen tardar un poco más en adaptar su código para ser compatible totalmente con las nuevas versiones.
También es algo común que muchos plugins se queden sin actualizaciones por el camino y nos veamos obligados a recurrir a otras alternativas para sustituirlos cuando queremos dar el salto de versión de PHP.
Es importante destacar que, en una instalación WordPress de blog o web estática, donde los visitantes cargan todo cacheado, la versión de PHP es un poco más indiferente, ya que solo se va a notar en el dashboard.
Sin embargo, en instalaciones complejas donde no se puede aplicar caché de página, tener una de las últimas versiones de PHP es una mejora considerable en la velocidad de carga y en el consumo de recursos.
Por poner un ejemplo, una tienda online WooCommerce o una plataforma LMS creada con LearnDash van a aprovechar muy bien la eficiencia de PHP8.
Hasta PHP 5.6 era muy común hablar de distintos OPCode Cache para PHP, o lo que es lo mismo, OPCache.
También se llamaban “aceleradores de PHP” o “PHP Accelerators” y se usaban como caché de archivos PHP preprocesados en memoria RAM.
Esto no quiere decir que ahora no se sigan usando, pero… realmente solo se ha quedado uno.
Estos son algunos de los que compartían cuota de mercado en la versión y su rendimiento:
Algunos OPCache como APC aún se siguen utilizando para otras tareas, como caché de objetos no distribuidos.
Al final, el ganador de la batalla ha sido Zend OPCache (el que jugaba en casa).
Zend OPCache era el mejor, y al final es el que se quedó integrado en el intérprete PHP de forma nativa, por lo que, a partir de la versión 7.0 de PHP, Zend OPcache viene integrado en el núcleo.
Muestro otra prueba donde solo se activa y desactiva el OPCache entre ambos benchmarks.
Este benchmark comparativo muestra la diferencia entre OPCache activado y desactivado en un Plan Inicio SSD de los nuestros usando PHP 7.4:
Como se puede observar en las capturas anteriores, con un OPCache casi conseguimos doblar el rendimiento a la hora de realizar operaciones con el intérprete PHP. Esto quiere decir que también conseguimos optimizar la carga de scripts y de CMS como WordPress.
De cara a los CMS, el OPCache funciona de forma transparente. Es decir, simplemente almacena archivos PHP en la RAM más o menos procesados (por decirlo de alguna manera) y los carga directamente desde el OPCache cuando se necesitan.
Esto hace que se consuma algo más de memoria RAM en el servidor, pero lo compensa con la mejora en la eficiencia y en el rendimiento.
Como punto final, añadir que a partir de PHP 7 el OPCache (Zend OPCache) viene integrado en el intérprete de PHP, aunque en muchos casos debemos activarlo para poder usarlo:
Una vez activado, empezará a funcionar de forma completamente transparente y sin nosotros tener que hacer nada.
Es muy raro encontrar problemas con el OPCache, ya que actualmente cualquier CMS o script está preparado para funcionar con él.
Yo, personalmente, considero algo imprescindible su activación actualmente, tanto desde el punto de vista de los recursos, como del rendimiento en sí.
Como he dicho en la sección anterior, hoy en día es muy raro encontrarnos con problemas entre el OPCache de PHP y un CMS (al menos un CMS actualizado).
En WordPress con el OPCache activado no tenemos que hacer nada para que funcione, aunque si queremos vaciar caché de OPCache o ver lo que contiene el OPCache debemos usar un plugin o un script externo.
En WordPress, mi recomendación es utilizar el plugin WP OPCache: https://es.wordpress.org/plugins/flush-opcache/
Se trata de un plugin gratuito que nos permite vaciar caché y ver los archivos PHP que hay dentro del OPCache y algunos datos sobre ellos.
Como puedes ver en las dos capturas anteriores, en la barra de administración de WordPress tenemos un botón llamado “Flush PHP OPcache” que nos sirve para vaciar el OPCache.
Esto es bastante útil cuando actualizamos plugins, desactivamos o desinstalamos plugins, aunque también es aplicable a cuando modificamos un archivo PHP en cualquier circunstancia.
Otros plugins de caché como WP Rocket tienen integración con el OPCache actualmente y nos permiten vaciarlo, aunque no nos permiten ver lo que hay dentro como el plugin WP OPCache.
Desde hace unos meses existe un plugin llamado Docket Cache que nos permite utilizar el OPCache como caché de objetos.
El OPCache y el caché de objetos son dos tipos de caché diferentes, aunque parecidos en muchos sentidos.
Mientras que el OPCache permite únicamente guardar archivos PHP, el Object Cache guarda literalmente “datos”.
Entonces… ¿Cómo usamos el OPCache como caché de objetos si solo nos permite guardar en archivos PHP? Pues… convirtiendo esos datos que se iban a guardar en el caché de objetos en archivos PHP.
Los datos se “serializan” en archivos PHP y cuando se necesitan se revierte el proceso, haciendo el plugin como intérprete.
En muchos casos esto puede ser contraproducente, pero como siempre en WordPress, cuando trabajamos con instalaciones complejas, todo es circunstancial.
Si quieres saber más sobre Docket Cache para WordPress, te recomiendo ver el vídeo que comparto a continuación, grabado por mí hace algún tiempo:
Este plugin se publicó en noviembre de 2020 y desde ese momento ha mejorado mucho. De hecho, ha añadido tweaks específicos para WooCommerce que son exclusivos de Docket Cache en algunos casos.
Ha ido mejorando el consumo de I/O y ha ido mejorando su eficiencia, aunque debemos ser conscientes de que, al usar soluciones como estas, el consumo de RAM del plan de hosting o servidor va a subir, aunque bajará el consumo de CPU.
Por otro lado, hay que aclarar que esta solución no siempre es idónea. Únicamente es “válida” cuando tenemos nuestra web alojada en un servidor de hosting compartido donde no están ni Memcached ni Redis instalado y necesitamos el Object Cache para acelerar nuestro sitio web complejo.
Prestashop sigue siendo uno de los CMS para ecommerce más utilizados a pesar de la “paliza” que le están pegando en cuota de mercado WooCommerce y Shopify.
Prestashop es un CMS complejo y a nivel PHP sobrecarga bastante la CPU y RAM. Además, el sistema de plantillas “Smarty” tampoco ayuda mucho.
En Prestashop tener el OPCache activo siempre es importante, ya que conseguiremos una mayor velocidad casi siempre.
Esto se debe a que el 99% de las tiendas Prestashop usan el caché de objetos nativo, pero no usan un caché de página específico, algo muy común en otros CMS como WordPress.
Activando el OPCache conseguiremos una mejora bastante importante en la ejecución de PHP y, por lo tanto, mejoraremos la carga del carrito y el checkout de cualquier ecommerce, incluido Prestashop.
Vuelvo a compartir la comparación entre ejecutar el mismo benchmark con el OPCache activado y desactivado:
Cuando más complejo sea el código PHP ejecutado, más se va a notar.
En los últimos años, han cambiado muchas cosas en torno a la acción de cambiar la versión de PHP en un hosting o servidor.
Durante mucho tiempo los servidores de hosting -e incluso los servidores VPS y dedicados- tenían una versión de PHP para todo el servidor y, si querías cambiarla, cambiaba en todo el servidor.
Más tarde se permitió personalizar la versión de PHP para cada cuenta, pero en la gran mayoría de casos había que contactar con el administrador del servidor para hacerlo.
Desde el año 2019 aproximadamente, es muy raro que el propio usuario no pueda cambiar la versión de PHP a nivel cuenta o incluso a nivel web, directamente desde su panel de control sin tener que contactar con un administrador.
Te dejo dos ejemplos.
Por un lado, en un servidor cPanel con CloudLinux como los que tenemos para hosting compartido (y sus variantes), hosting elastico y hosting reseller en Raiola Networks puedes cambiarlo directamente desde el cPanel:
Y te permitirá elegir entre las versiones de PHP más comunes, y también seleccionar los módulos cargados:
Pero no solo eso, sino que en otros paneles de control como VestaCP, el que usamos para nuestros servidores VPS optimizados, también permitimos cambiar la versión de PHP:
Aunque en este caso el cambio no va a nivel cuenta entera, sino que va a nivel dominio o vhost.
Incluso en stacks LEMP sin panel, como puede ser CentMinMod, es muy fácil cambiar la versión de PHP con los scripts incluidos en el stack sin necesidad de hacer todo el proceso manualmente.
Como puedes ver, actualmente cambiar la versión de PHP en tu hosting o servidor para adaptarla a tu sitio web es muy fácil y realmente merece la pena acercarse a las versiones más recientes y más optimizadas de PHP.
La tabla anterior puedes verla actualizada en esta URL: https://w3techs.com/technologies/overview/programming_language
Pero de estos porcentajes no solo debemos interpretar los números que vemos, sino también las gráficas de crecimiento o pérdida de cuota de mercado.
Mientras que PHP se mantiene e incluso sube un poco: https://w3techs.com/diagram/history_technology/pl-php
El segundo competidor, ASP.NET baja muy rápido: https://w3techs.com/diagram/history_technology/pl-aspnet
Bien es cierto que hay algunas tecnologías SSI (Server Side Rendering) que suben cuota de mercado bastante rápido, como Javascript o Ruby. Sin embargo, todavía están lejos de PHP.
En los últimos años PHP ha mejorado muchísimo en efectividad, consiguiendo un mejor rendimiento y un menor consumo de recursos.
Podemos decir que PHP 8 ha mejorado la eficiencia casi un 400% frente a PHP 5.6.
Recordemos que PHP 7.0 se publicó en 2015, pero no tuvo una fuerte implementación hasta 2016-2017. Es decir, poco a poco se fue dejando de usar PHP 5.6.
Con esto quiero decir que, en apenas 5 años de actualizaciones, PHP ha conseguido doblar e incluso triplicar el rendimiento y bajar el consumo de recursos.
Aunque el rendimiento y la eficiencia no ha sido la única mejora de PHP 7 y PHP 8 frente a PHP 5.6, en ciertos ambientes “no técnicos” ha sido la que más ha llamado la atención.
Índice del artículo
- Benchmark de PHP
- PHP 8 y WordPress
- PHP 8, PHP 7 y el OPCache
- OPCache y WordPress
- Usar el OPCache como Object Cache en WordPress
- OPCache y Prestashop
- Cambiar la versión de PHP en un hosting o servidor
Benchmark de PHP
Como hemos comentado anteriormente, una de las cosas que más ha destacado en PHP a lo largo de estos años han sido las mejoras de rendimiento.
Para que veas a lo que me refiero, la siguiente gráfica representa unos benchmarks (pruebas) de rendimiento realizados en un Plan Inicio SSD de Raiola Networks con las distintas versiones de PHP desde la 7.0 hasta la 8.0.
Como se puede observar, desde la versión 7.0 hasta la versión 8.0 se dobla prácticamente la velocidad en la ejecución de operaciones con el intérprete PHP.
Pero hay más, ya que, si prestas atención a este otro gráfico, te darás cuenta de que desde la versión 5.1 de PHP se ha cuadruplicado el rendimiento:
Esto no quiere decir que tengamos que actualizar a una nueva versión de PHP siempre que esté disponible, simplemente nos recuerda que -al menos por WPO- es imprescindible no quedarse atrás.
Cuando sale una nueva versión de PHP normalmente ni los CMS ni los plugins son compatibles, ya que cambian código en el intérprete PHP y necesitamos que los desarrolladores los cambien en el código de sus aplicaciones para no tener problemas.
Por ejemplo, WordPress es compatible con PHP 8 desde la versión 5.6. Es decir, ha tardado 9 meses desde la salida de PHP 8 en ser compatible.
Sin embargo, en a fecha de 30 agosto de 2021, solo el 60% de los plugins del repositorio son compatibles con PHP8, por lo que todavía hay muchísimos plugins que no soportan esta versión de PHP y que, si los usáramos, no podríamos pasar de PHP 7.4 a PHP 8.
PHP 8 y WordPress
Profundizando más en el tema de los principales CMS del mercado trabajando con las nuevas versiones de PHP, nos encontramos que el núcleo de WordPress se adapta rápidamente a las nuevas versiones de PHP.
Recuerdo bastante bien cuando hace unos años WordPress empezó a funcionar con PHP 7.0. La velocidad conseguida al realizar este cambio fue brutal, y un consultor WPO como yo se acuerda de estas cosas.
Aunque con la versión 8.0 de PHP no se ha conseguido el mismo salto en lo que a velocidad de carga se refiere, podemos decir que sí ha mejorado bastante. Esto resalta más si comparamos PHP 7.0 con PHP 8, pasando por todas las ramas PHP 7.X.
Como hemos mencionado anteriormente, el núcleo de WP se adapta rápidamente a las nuevas versiones de PHP, pero cabe destacar que los desarrolladores de los plugins suelen tardar un poco más en adaptar su código para ser compatible totalmente con las nuevas versiones.
También es algo común que muchos plugins se queden sin actualizaciones por el camino y nos veamos obligados a recurrir a otras alternativas para sustituirlos cuando queremos dar el salto de versión de PHP.
Es importante destacar que, en una instalación WordPress de blog o web estática, donde los visitantes cargan todo cacheado, la versión de PHP es un poco más indiferente, ya que solo se va a notar en el dashboard.
Sin embargo, en instalaciones complejas donde no se puede aplicar caché de página, tener una de las últimas versiones de PHP es una mejora considerable en la velocidad de carga y en el consumo de recursos.
Por poner un ejemplo, una tienda online WooCommerce o una plataforma LMS creada con LearnDash van a aprovechar muy bien la eficiencia de PHP8.
PHP 8, PHP 7 y el OPCache
Hasta PHP 5.6 era muy común hablar de distintos OPCode Cache para PHP, o lo que es lo mismo, OPCache.
También se llamaban “aceleradores de PHP” o “PHP Accelerators” y se usaban como caché de archivos PHP preprocesados en memoria RAM.
Esto no quiere decir que ahora no se sigan usando, pero… realmente solo se ha quedado uno.
Estos son algunos de los que compartían cuota de mercado en la versión y su rendimiento:
Algunos OPCache como APC aún se siguen utilizando para otras tareas, como caché de objetos no distribuidos.
Al final, el ganador de la batalla ha sido Zend OPCache (el que jugaba en casa).
Zend OPCache era el mejor, y al final es el que se quedó integrado en el intérprete PHP de forma nativa, por lo que, a partir de la versión 7.0 de PHP, Zend OPcache viene integrado en el núcleo.
Muestro otra prueba donde solo se activa y desactiva el OPCache entre ambos benchmarks.
Este benchmark comparativo muestra la diferencia entre OPCache activado y desactivado en un Plan Inicio SSD de los nuestros usando PHP 7.4:
Como se puede observar en las capturas anteriores, con un OPCache casi conseguimos doblar el rendimiento a la hora de realizar operaciones con el intérprete PHP. Esto quiere decir que también conseguimos optimizar la carga de scripts y de CMS como WordPress.
De cara a los CMS, el OPCache funciona de forma transparente. Es decir, simplemente almacena archivos PHP en la RAM más o menos procesados (por decirlo de alguna manera) y los carga directamente desde el OPCache cuando se necesitan.
Esto hace que se consuma algo más de memoria RAM en el servidor, pero lo compensa con la mejora en la eficiencia y en el rendimiento.
Como punto final, añadir que a partir de PHP 7 el OPCache (Zend OPCache) viene integrado en el intérprete de PHP, aunque en muchos casos debemos activarlo para poder usarlo:
Una vez activado, empezará a funcionar de forma completamente transparente y sin nosotros tener que hacer nada.
Es muy raro encontrar problemas con el OPCache, ya que actualmente cualquier CMS o script está preparado para funcionar con él.
Yo, personalmente, considero algo imprescindible su activación actualmente, tanto desde el punto de vista de los recursos, como del rendimiento en sí.
OPCache y WordPress
Como he dicho en la sección anterior, hoy en día es muy raro encontrarnos con problemas entre el OPCache de PHP y un CMS (al menos un CMS actualizado).
En WordPress con el OPCache activado no tenemos que hacer nada para que funcione, aunque si queremos vaciar caché de OPCache o ver lo que contiene el OPCache debemos usar un plugin o un script externo.
En WordPress, mi recomendación es utilizar el plugin WP OPCache: https://es.wordpress.org/plugins/flush-opcache/
Se trata de un plugin gratuito que nos permite vaciar caché y ver los archivos PHP que hay dentro del OPCache y algunos datos sobre ellos.
Como puedes ver en las dos capturas anteriores, en la barra de administración de WordPress tenemos un botón llamado “Flush PHP OPcache” que nos sirve para vaciar el OPCache.
Esto es bastante útil cuando actualizamos plugins, desactivamos o desinstalamos plugins, aunque también es aplicable a cuando modificamos un archivo PHP en cualquier circunstancia.
Otros plugins de caché como WP Rocket tienen integración con el OPCache actualmente y nos permiten vaciarlo, aunque no nos permiten ver lo que hay dentro como el plugin WP OPCache.
Usar el OPCache como Object Cache en WordPress
Desde hace unos meses existe un plugin llamado Docket Cache que nos permite utilizar el OPCache como caché de objetos.
El OPCache y el caché de objetos son dos tipos de caché diferentes, aunque parecidos en muchos sentidos.
Mientras que el OPCache permite únicamente guardar archivos PHP, el Object Cache guarda literalmente “datos”.
Entonces… ¿Cómo usamos el OPCache como caché de objetos si solo nos permite guardar en archivos PHP? Pues… convirtiendo esos datos que se iban a guardar en el caché de objetos en archivos PHP.
Los datos se “serializan” en archivos PHP y cuando se necesitan se revierte el proceso, haciendo el plugin como intérprete.
En muchos casos esto puede ser contraproducente, pero como siempre en WordPress, cuando trabajamos con instalaciones complejas, todo es circunstancial.
Si quieres saber más sobre Docket Cache para WordPress, te recomiendo ver el vídeo que comparto a continuación, grabado por mí hace algún tiempo:
Este plugin se publicó en noviembre de 2020 y desde ese momento ha mejorado mucho. De hecho, ha añadido tweaks específicos para WooCommerce que son exclusivos de Docket Cache en algunos casos.
Ha ido mejorando el consumo de I/O y ha ido mejorando su eficiencia, aunque debemos ser conscientes de que, al usar soluciones como estas, el consumo de RAM del plan de hosting o servidor va a subir, aunque bajará el consumo de CPU.
Por otro lado, hay que aclarar que esta solución no siempre es idónea. Únicamente es “válida” cuando tenemos nuestra web alojada en un servidor de hosting compartido donde no están ni Memcached ni Redis instalado y necesitamos el Object Cache para acelerar nuestro sitio web complejo.
OPCache y Prestashop
Prestashop sigue siendo uno de los CMS para ecommerce más utilizados a pesar de la “paliza” que le están pegando en cuota de mercado WooCommerce y Shopify.
Prestashop es un CMS complejo y a nivel PHP sobrecarga bastante la CPU y RAM. Además, el sistema de plantillas “Smarty” tampoco ayuda mucho.
En Prestashop tener el OPCache activo siempre es importante, ya que conseguiremos una mayor velocidad casi siempre.
Esto se debe a que el 99% de las tiendas Prestashop usan el caché de objetos nativo, pero no usan un caché de página específico, algo muy común en otros CMS como WordPress.
Activando el OPCache conseguiremos una mejora bastante importante en la ejecución de PHP y, por lo tanto, mejoraremos la carga del carrito y el checkout de cualquier ecommerce, incluido Prestashop.
Vuelvo a compartir la comparación entre ejecutar el mismo benchmark con el OPCache activado y desactivado:
Cuando más complejo sea el código PHP ejecutado, más se va a notar.
Cambiar la versión de PHP en un hosting o servidor
En los últimos años, han cambiado muchas cosas en torno a la acción de cambiar la versión de PHP en un hosting o servidor.
Durante mucho tiempo los servidores de hosting -e incluso los servidores VPS y dedicados- tenían una versión de PHP para todo el servidor y, si querías cambiarla, cambiaba en todo el servidor.
Más tarde se permitió personalizar la versión de PHP para cada cuenta, pero en la gran mayoría de casos había que contactar con el administrador del servidor para hacerlo.
Desde el año 2019 aproximadamente, es muy raro que el propio usuario no pueda cambiar la versión de PHP a nivel cuenta o incluso a nivel web, directamente desde su panel de control sin tener que contactar con un administrador.
Te dejo dos ejemplos.
Por un lado, en un servidor cPanel con CloudLinux como los que tenemos para hosting compartido (y sus variantes), hosting elastico y hosting reseller en Raiola Networks puedes cambiarlo directamente desde el cPanel:
Y te permitirá elegir entre las versiones de PHP más comunes, y también seleccionar los módulos cargados:
Pero no solo eso, sino que en otros paneles de control como VestaCP, el que usamos para nuestros servidores VPS optimizados, también permitimos cambiar la versión de PHP:
Aunque en este caso el cambio no va a nivel cuenta entera, sino que va a nivel dominio o vhost.
Incluso en stacks LEMP sin panel, como puede ser CentMinMod, es muy fácil cambiar la versión de PHP con los scripts incluidos en el stack sin necesidad de hacer todo el proceso manualmente.
Como puedes ver, actualmente cambiar la versión de PHP en tu hosting o servidor para adaptarla a tu sitio web es muy fácil y realmente merece la pena acercarse a las versiones más recientes y más optimizadas de PHP.
Deja una respuesta
Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *