Programación y Estrategias de Negocios RSS 2.0
# Tuesday, August 21, 2007

Este post es una continuación del anterior sobre FastCGI y el IIS7, en Windows 2008 Beta 3 y Windows Vista, se incluye como soporte nativo FastCGI, lo que permite correr en maquinas Windows aplicaciones PHP y otros lenguajes de Script con altísimo rendimiento y estabilidad, incluso en ambientes en producción. El FastCGI CTP preview 2 también pueden montarse sobre IIS 5.1 y 6.0.

En este post, más allá de las instrucciones de cómo instalar una aplicación PHP en Windows Vista o Windows 2008, hablaré un poco de las razones por las que el rendimiento de las aplicaciones se incrementa al usar FastCGI.

Primero un poco de Antecedentes.

Common Gateway Interface (CGI)

El estándar de facto para aplicaciones en servidores web es CGI, que fue implementado inicialmente por el servidor NCSA. CGI tiene varios beneficios:

· Simplicidad. es fácil de entender

· Independencia del Lenguaje. Las aplicaciones CGI pueden ser escritas en cualquier lenguaje

· Independencia de Procesos. Ya que las aplicaciones corren en procesos separados, las aplicaciones con problemas no pueden dañar el servidor web o acceder al estado interno y privado del servidor.

· Estándar Abierto. Alguna forma de CGI ha sido implementada en todos los servidores web

· Independencia Arquitectónica. CGI no está atado a ninguna arquitectura particular de servidor 

CGI también tiene algunas deficiencias importantes. El problema principal es el rendimiento: debido a que se crea un nuevo proceso para cada request y este se elimina cuando el request se completa, la eficiencia es pobre.

CGI también tiene una funcionalidad limitada: solo soporta el Rol "responder", donde la aplicación genera la respuesta que es enviada al cliente, los programas CGI no pueden asociarse a otras partes del procesamiento del request como autorización o registro de errores.

 

APIs de Servidor

En respuesta a los problemas de rendimiento de CGI, diferentes compañías han desarrollado APIS para sus servidores. Los dos más relevantes son NSAPI de Netscape e ISAPI de Microsoft. El servidor Apache también tiene un API.

Las aplicaciones asociadas al API del servidor pueden correr mucho más rápido que los programas CGI. El problema del Inicio / iniciación se ha mejorado, ya que la aplicación corre en un proceso dedicado de servidor y se persiste entre las solicitudes. Las API del servidor Web, ofrecen mucha más funcionalidad que CGI, cada persona puede escribir extensiones que realizan control de accesos, acceder a los archivos de registro del servidor, y pueden conectarse en otras etapas del procesamiento del request. 

 

Entonces que es  FastCGI?

La interface FastCGI combina los mejores aspectos de CGI y las APIs propietarias. Como CGI, las aplicaciones FastCGI corren en procesos separados e independientes. Las ventajas de FastCGI's incluyen:

· Rendimiento. Los procesos FastCGI son persistentes –se re usan en manejar múltiples solicitudes. – Esto resuelve los problemas de rendimiento de CGI de crear nuevos procesos para cada request.

· Simplicidad, fácil migración desde CGI. La librería de aplicación FastCGI simplifica la migración de las aplicaciones CGI existentes. Las aplicaciones construidas con FastCGI pueden correr programas CGI para compatibilidad con Web Servers antiguos.

· Independencia de Language. Como CGI, las aplicaciones FastCGI pueden ser escritas en cualquier lenguaje.

· Independencia de Procesos. Una aplicación FastCGI con errores no puede corromper el core del servidor web o alguna otra aplicación. Una aplicación FastCGI no puede robar ningún secreto (como las llaves de sesión para encripción) del servidor Web.

· No-propietario. FastCGI es soportado por todo los productos del Open Source del Mercado, incluyendo apache, NCSA y ahora es soportado por servidores comerciales de Microsoft y Netscape.

· Independencia Arquitectónica. La interface FastCGI no está atada a ninguna arquitectura particular de servidor. Cualquier servidor puede implementar la interface FastCGI. De igual manera, FastCGI no impone ninguna arquitectura a la aplicación: las aplicaciones pueden ser single o multi-threaded, sin importar la arquitectura de hilos del servidor web.

· Soporte para computación distribuida. FastCGI prove soporte para correr aplicaciones remotamente, lo cual es útil para distribuciones de carga y manejo externo de web sites.

 

La interface FastCGI

La funcionalidad que provee la interface FastCGI es muy similar a la que provee CGI. Para entender mejor el protocolo FastCGI. El procesamiento de peticiones CGI es así:

1. Para cada Request, el servidor crea un nuevo proceso y el proceso se inicializa por sí mismo.

2. El servidor web pasa la información del request( como host remoto, nombre de usuario, encabezados HTTP, etc) a las variables  de entorno del programa CGI.

3. El web server envía cualquier input del cliente  (como valores entrados por el usuario en un formulario HTML) al estándar input del programa CGI.

4. El programa CGI escribe cualquier output para que sea retornado al cliente como salida estándar. La información de error es escrita por el web server.

5. Cuando el proceso CGI se cierra, la solicitud queda completa.

FastCGI es conceptualmente muy similar a CGI, con dos diferencias principales:

· Los procesos FastCGI son persistentes: después de finalizar una solicitud, los procesos quedan en espera en vez de finalizar. 

· En vez de usar variables de ambiente del sistema operativo y pipes,  el protocolo  FastCGI multiplexa la información del ambiente, el input  estándar, el output estándar y error sobre una conexión full-duplex. Esto permite a los programas FastCGI correr en maquinas remotas, usando conexiones TCP entre el servidor web y las aplicaciones FastCGI.

El procesamiento de una solicitud en una aplicación single-threaded FastCGI ocurre así :

1. El Web server crea la aplicación FastCGI para manejar las solicitudes al servidor. El proceso puede ser creado en el inicio o creado por demanda.

2. El programa FastCGI seinicializa  por sí mismo, y espera una nueva conexión con el web server.

3. Cuando llega una solicitud de un cliente, el servidor  web abre una conexión a los procesos FastCGI. El servidor envía la información de ambiente y el input estándar sobre la conexión.

4. el proceso FastCGI envía la salida estándar y la información de errores de regreso al servidor sobre la misma conexión. 

5. Cuando el proceso  FastCGI cierra la conexión, la solicitud se completa. El proceso FastCGI queda a la espera de otra conexión desde el servidor web.

Las FastCGI pueden correr localmente  (en la misma máquina que el web server) o remotamente. Para aplicaciones locales, el servidor usa un  full-duplex pipe para conectarse con el proceso de la aplicación  FastCGI . Para aplicaciones remotas, el servidor usa conexiones TCP.

Las aplicaciones FastCGI pueden ser  single-threaded or multi-threaded. para aplicaciones  single threaded, el servidor web mantiene un pool de procesos  (si la aplicación corre localmente) para manejar las solicitudes de los clientes. El tamaño del Pool es configurable por el usuario. Las aplicaciones FastCGI Multi-threaded pueden recibir múltiples conexiones del web server y manejarlas de forma simultánea en un solo proceso.  (De esta forma lenguajes, con soporte para multi thead, garballe collection, entre otros, lo hacen lenguajes naturales para implementar aplicaciones multithread usando FastCGI)

 

Roles de Aplicación.

Un problema importante con CGI es su funcionalidad limitada: los programas CGI solo proveen respuestas simples al request.  FastCGI provee funcionalidad ampliada con soporte para tres diferentes roles de aplicación: 

· Responder. este es el rol básico en  FastCGI y corresponde a la funcionalidad básica ofrecida por CGI hoy. 

· Filter. las aplicaciones FastCGI filtran los archivos solicitados al web server antes de que sean enviados al cliente. 

· Authorizer. El programa FastCGI realizan una decisión de control de acceso para el request ( por ejemplo realizando una búsqueda a la base de datos del tipo Usuario/password).

Otros roles serán definidos en el futuro. Por ejemplo,  un rol "logger" podría ser útil, donde el programa FastCGI podría recibir el registro del log del servidor para procesamiento y análisis en tiempo real. 

 

Que tan rápido es FastCGI?

La respuesta depende de la aplicación, algunas pruebas hechas en internet muestra lo siguiente:

En esta medición se usa un archivo, una solicitud CGI y una fastCGI, usando una aplicación que retorna un número fijo de bytes. 

Archivo  

21ms + 0.19ms per Kbyte

FastCGI

22ms + 0.28ms per Kbyte

CGI

59ms + 0.37ms per Kbyte

Con este dato podemos trata de calcular la velocidad después de migrar una aplicación típica CGI de base de datos a FastCGI, asumiendo que la aplicación toma 50ms para inicializar las conexiones a las bases de datos y genera 5k de datos. Los resultados finales pueden calcularse así: 

CGI

59ms + 50ms + (0.37ms)(5) = 111ms

FastCGI

22ms + (0.28ms)(5) = 23ms

En esta prueba, FastCGI tuvo una ventaja de rendimiento de 5x sobre CGI, más que nada debido a no tener que crear e iniciar un nuevo proceso para cada solicitud.

 

En resumen

FastCGI es un protocolo estándar que permite a ejecutables que usen Frameworks CGI interactuar con un Web Server.

La mayor diferencia con el Protocolo CGI Estándar es que FastCGI rehúsa los Procesos CGI para múltiples peticiones, lo que incrementa el rendimiento en comparación con CGI.

El soporte de IIS para FastCGI permite a IIS hospedar programas CGI normales como PHP, o Ruby On Rails, usando el protocolo FastCGI, ofreciendo alto rendimiento y estabilidad en ambientes de producción

Para usar el soporte  FastCGI en IIS se requieren tres elementos:

· El web server IIS (IIS5.1, IIS6, and IIS7).

· El componente FastCGI para IIS

· EL programa CGI que será hospedado.

Como funciona?

El servidor web despacha las solicitudes http que se han realizado a su aplicación usando el componente FastCGI, este a su vez lanza el programa ejecutable CGI y reenvía el request para que sea procesado. Una vez la solicitud se procesa y la respuesta se finaliza y es retornada al servidor y al cliente, el proceso CGI es usado para llamadas siguientes. Esto permite evita las penalidades de alto rendimiento de iniciar un nuevo proceso para cada solicitud, lo que resulta en mucho mejor rendimiento y escalabilidad en ambientes de producción.

El protocolo FastCGI es estándar si quiere tener más información sobre FastCGI puede ver más aquí. http://www.fastcgi.com/devkit/doc/fcgi-spec.html.

El paquete FastCGI es totalmente compatible con la distribución actual y oficial  PHP 5.x disponible para Windows desde  www.php.net/downloads. También puede usar el preview de Fast CGI con la instalación existente de  PHP 5.x (sin embargo usar la versión ThreadSafe incrementa el rendimiento hasta un 30%)

La versión 5.2.3 también contiene las mejoras desarrolladas por Zend para mejorar el rendimiento del motor de PHP sobre Windows.

Espero que sea de Ayuda

Juan Carlos Peláez

MCTS

Miembro del Microsoft Speaker Group Andino  

Miembro del Microsoft Influencers Group de Colombia.

Keywords: PHP, FastCGI, Windows Vista, Windows 2008, IIS7, Arquitectura.

Tuesday, August 21, 2007 9:20:38 AM (SA Pacific Standard Time, UTC-05:00)  #    Comments [0] - Trackback
Arquitectura | Articulos de Desarrollo | FastCGI | IIS7 | PHP | Windows Server 2008 | Windows Vista
Comments are closed.
Contácteme
mail: jpelaez at juanpelaez.com
Archivo
<January 2009>
SunMonTueWedThuFriSat
28293031123
45678910
11121314151617
18192021222324
25262728293031
1234567
FeedBurner
Maps
Locations of visitors to this page
Sponsors
Acerca de...

Aviso Legal
Las opiniones expresadas en este sitio representan el punto de vista de Juan Peláez sobre diferentes temas y no representan la posición de Studiocom.com.Inc, Microsoft. o de cualquier otra compañía que haya contratado los servicios de consultoría de Juan Peláez

© Copyright 2009
Juan Carlos Peláez
Sign In

Technorati Profile
Estadísticas
Total Posts: 73
This Year: 0
This Month: 0
This Week: 0
Comments: 14
All Content © 2009, Juan Carlos Peláez
El tema 'Business' para DasBlog fue creado por Christoph De Baene (delarou) y modificado para espa�ol por Juan Peláez
Powered by FeedBurner