Estoy instalando una máquina con CentOS 7 esperando encontrarme con la última versión estable de PHP, la 7.1.10, y me doy cuenta de que en los repos de CentOS 7 van apenas en PHP 5.4.16.
Consulta:
¿Vale la pena pegarse el salto a PHP 7? Igual el salto es grande, voy a estar adelantado como tres cuadras con respecto al resto de las instalaciones estándar. Mi necesidad es migrar el código de una aplicación vieeeeeja que vive en un PHP 4.3. Es una aplicación web de uso interno con poca demanda que se conecta a una base de datos Oracle.
Si vale la pena el salto, ¿existe una forma de instalar PHP 7 mediante yum configurando repositorios?
Ping
@unreal4u @BalroG @ranamaldita @Amenadiel @Potus @Pontifex_Es .
Respuesta corta: SIIIIIIIIIIIIIIIII!!!!!!!!! Sin embargo, lee mis demás respuestas antes de.
El repo webtatic.com tiene php7 para centos 7
Pero migrar de php4 a php7 no es tan facil como podria ser.
Con webtatic NI A MISA! Es una repo más inestable y "tocado" que la cresta... si quieres algo oficial, ándate por remi, es además el RM (release manager) de PHP7.2 que saldrá creo que en 4 días más y será un release chico que no cambia mucho lo anterior y sólo agrega funcionalidad + mejoras en velocidad (chicas), así que ándate mejor por PHP7.2. Como dije, remi es RM así que algo debe cachar.
PHP7.3 será otro gran release donde (hasta el momento) activarán JIT, haciendo que las llamadas a funciones donde se ocupe type hinting sea muuuuuuuucho más rápido, creo que querían un 20% como mínimo, pero todavía falta al menos año y medio para eso, así que por el momento no se puede prometer nada.
Tenía entendido que PHP7 trajo harto avance en desempeño.
Será tan así?
1,
2
Valdrá la pena la ganancia en desempeño con el costo en implementación?
Sí, de PHP5.6 a PHP7 es entre un 30% a un 80% más rápido. A nosotros con PHP5 apenas nos daba abasto con 2 frontends (estábamos planificando poner 2 frontends adicionales), y ahora estamos con 1 y relajados, incluso en aquellos momentos en que salimos en la tele y nos llega una lluvia de tráfico que dura media hora.
Si actualizas desde PHP4 debe ser del orden de 150%... mínimo. Como nota adicional: desde PHP5.4 aprox. que existe una batería de tests asegurando que cada release no introduzca regresiones. Es decir que desde PHP5.4 en adelante puedes estar bastante seguro que una vez arreglados las BC que publican en cada release, no vas a tener problemas corriendo tu aplicación. En su gran mayoría, son chicos, excepto para releases que cambian de versión mayor.
Dejalo como esta, a menos que quiera optimizar tu app para ser compatible con php7, lo otro es que pruebes la app con un docker con php 7
https://hub.docker.com/r/nimmis/apache-php7/ y veas que tal anda, para ver si vale la pena buscar el repo de php7
Totalmente de acuerdo con barlolo: de PHP4 a 7 hay muuuucha diferencia, así que pruébalo antes de. Partiendo por tu coso en Oracle que la verdad no sé si se ocupe todavía el mismo controlador, creo que se cambió, así que eso significa re-escribir TODAS las queries que se ejecutan. Considerando además los magic quotes y otras "gracias" de PHP4 no creo que llegues muy lejos antes de tirar la esponja xD
Pero si le das, pues yo ocupo vagrant antes que Docker, pero la idea base es la misma: creas una máquina virtual, corres tu código en él y ves cómo anda.
Scripts para hacer esto? Pues ve mis repos en github:
https://github.com/unreal4u/telegram-api/blob/master/Vagrantfile
Eso combinado con esto:
https://github.com/unreal4u/telegram-api/blob/master/VagrantProvisionScripts/base.sh
Crea una máquina virtual con la última versión de PHP7.1 (no olvidar cambiar a PHP7.2 en un par de días más). Te vas al directorio, copias ambos archivos de arriba más otras customizaciones que quieras hacer, ejecutas en tu terminal:
Y listo, en 192.168.33.10 tendrás corriendo un server. Con eso pruebas y arreglas antes de tirarlo a producción.
Una vez que quieras instalar en producción, ya sea bare metal o vm, tendrás un paso a paso documentado de cómo quieres montar el servidor. Lógicamente antes vas probando quitando y agregando los módulos que ocupes. Menos módulos: menos que cargar en cada request, más rápido y menor footprint de memoria va a tener tu aplicación.
Saludos.
PD::: en mi script desactivo SELinux, te recomiendo NO hacer esto, pero ese script lo copié de la pega donde me dio paja instalar los permisos correctos (Además el use-case es bastante más amplio y complejo que correr una simple página, en producción sí tenemos habilitado SELinux, sólo durante desarrollo se desactiva).
Nuestra OTAP se ve como desarrollo - staging - acceptance - production
Desde staging tenemos activado SELinux así que cualquier cosa que tenga que ver con permisos ya se ve en esa etapa. A la hora que llegue donde el cliente ya debería estar todo arreglado y documentado para que de ahí recién pase a producción.
