Home / PHP / PHP handlers

PHP handlers

Una más cosas que tenemos que estar consientes como systadmin, es saber cómo está comportando nuestro servidor y como este está funcionando, al tener un servicio WEB y PHP podemos elegir un manejador o interpretador para la comunicación de scripts en php y como estos van a ser entregados por un servidor web(Apache, IIS, Nginx), Se interpreta el código PHP a partir de una biblioteca(librería) y determinan el como PHP va ser cargado en el servidor.

Hay diferentes handlers que puedes ser usado para cargar PHP como son:

  • DSO
  • CGI
  • suPHP
  • FastCGI

Cada handler tiene sus propias librerías y afecta directamente al performance de Apache (Nginx, etc) y del servidor ya que determina como Apache sirve a PHP, cada una con beneficios y desventajas al usar una determinada.

 

Cuál es la mejor

Todo depende del escenario en que estemos y a qué situación nos queremos enfrentar, decir que una es mejor que otra no es realmente cierto ya como lo mencione cada una nos ofrece distintos beneficios para esto explicare brevemente de que trata cada una de estas, asi a la hora de realizar una elección tomar el costo-beneficio…

 

Nota: Si tenemos en nuestro sistema diferentes versiones PHP podemos asignarle un handler a cada una, por ejemplo correr PHP5 en FastCGI y PHP4 en DSO.

suPHP

Este es el valor predeterminado en algunos paneles como cPanel, suPHP corre código PHP en un proceso diferente al servicio de Apache similar como lo hace CGI, la diferencia es  si activamos la opción de suEXEC  podremos ver cuál es la cuenta de usuario que está ejecutando el script PHP. Una de las ventajas es que podemos detectar sombre que usuario esta consumiendo grandes cantidades recursos y asi poder tomar medidas.

El tema de la Seguridad aumenta, al tener procesos por usuario, los archivos y script serán propios de cada uno, lo que significa que un script  tendrá un dueño, con sus respectivos permisos ( sistemas Unix  User, Group, Nobody) en archivos con permisos 777 que podrían manipularse por cualquiera podemos cambiarlo a 755 o 644 para directorios.

La particularidad es que si un sitio es expuesto solo ese será afectado dejando a los demás libres de cualquier eventualidad (redundancia) ya que el sitio ex puerto corresponde a un usuario y este no podrá interferir con los demás.

La principal desventaja de supo es la velocidad y el alto consumo de CPU. También no podremos trabajar con  una extensión de caching ya que sería la parte el gran consumo de CPU.

Lo que es recomendable para servidores multi sitio, por sus ventajas en seguridad.

 

 

DSO

También llamado mod_php (libphp4.so o libphp5.so), se considera el hadler mas rápido por su rápida respuesta en las solicitudes de PHP ya que este se ejecuta directamente desde Apache, sin tener procesos separados, lo que significa que apache y PHP correan como si fuera único proceso y correrán bajo el usuario de apache que en la gran mayoría es el usuario nobody, el consumo de recursos es relativamente bajo, por los que seria la manera ideal de servidores con un solo sitio.

En DSO hay que tener en cuenta dos cosas nuestros scripts deberán tener permiso de asignación del usuario nobody y cualquier archivo creado por el servidor web (fwrite) propiedad de nobody

El tema de los permisos hay que tomarlo en cuenta para considerar el tema de la seguridad, en algunos CMS requieren permisos 777 la idea es hacer un archivo con permisos de escritura para su funcionamiento esto no será obligado, los permisos en realidad serán  664 por ‘owed’ de usuario y grupo nobody para los directorios bastara con 775 user:nobody.

Sabemos que nuestro sistema está  corriendo en nobody por lo que un exploit en un sitio podría afectar a los demás ya que están compartiendo el mismo usuario.

La gran ventaja es velocidad y los pocos recursos que necesita para su funcionamiento si sumamos un plugin de cacgung como eAccekerator o APC, tendremos una velocidad mucho mayor.

 

CGI

CGI, provee la versión seleccionada de PHP por medio de mod_cgi o mod_cgid. Habilitando la opción de suEXEC podemos sobre qué cuenta de usuario está corriendo un script. En si este controlador está pensando como un handler de reserva cuando DSO no está disponible. Este método no es rápido ni seguro, sin importar si suEXEC está activado o no. Lo cual no sería recomendable para su uso, salvo su idea original de creación.

 

FastCGI

FCGI son siglas para fast CGI, otra implementación del handler CGI. Trata de minimizar el gasto general de la conexión de Apache con los programas CGI. Esto permite que el servidor sirva más páginas web con más rapidez, es muy similar a suPHP en el aspecto que cuenta con procesos separados, asi como también las ventajas de permisos sompre los ficheros. La diferencia con suPHP es el control de los procesos de PHP, suPHP corre en el mismo instante proceso de apache y php cuando FatCGI deja un proceso persistente para conexiones abiertas lo que deja el mismo proceso ya ejecutado de PHP para una petición similar.

Tenemos la gran posibilidad de usar extenciones de caching como eAcceleartor o APC lo que incrementara el performance.

El punto malo es su gran consumo de memoria RAM para poder manter las conexiones persistentes

 

Una buena analogía de suPHP y FastCGI es un libro con muchos capítulos, cuando suPHP necesita alguna información del libro este la estará buscando sin ninguna tabla de contenidos ni un índex, lo cual tendrá que generar una búsqueda del libro de lo que necesita lo cual le tomara un tiempo considerable ( lo que incrementa en uso de CPU) y que causa su lentitud ; Con FastCGI tendremos el libro con una gran cantidad de tablas de contendidos( procesos persistentes), por lo cual fácilmente podemos encontrar lo necesitamos. Pero las paginas adicióneles del   libro como son el index y tablas de contenidos tendremos un libro de muchas páginas ( causa el aumento de memoria para mantearlo).

About zero

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *