Hola,
Interesante lo que dices; pero, me entran dudas porque, al menos aparentemente, la valoración del aspecto principal no coincide con la información que tengo desde hace mucho. Para claridad de cualquier otro que consulte este hilo, detallo lo que sé;
En Windows, la idea de la tecnología ISAPI (y de NSAPI, su contraparte Netscape) es que el DLL se carga en memoria cuando su efectua una primera petición de sus servicios. De ahí en adelante, el DLL permanece en memoria; de tal forma que cualquier nueva petición no implica leer otra vez el DLL desde disco. El DLL solo será descargado automáticamente de memoria bajo 3 circunstancias:
1. Cuando ocurra un error realmente crítico
2. Cuando el tiempo de inactividad transcurrido (tiempo sin recibir una nueva petición), exceda un límite de tolerancia establecido
3. Cuando se descargue el servidor (IIS, Apache, etc)
Este es el esquema más rápido posible en términos de consumo de recursos por parte del aplicativo en sí. Su debilidad es la posibilidad de que, por errores de programación, una petición con errores provoque un desastre mayor ya que los recursos se están compartiendo (por ejemplo, que una petición no libere recursos; con el tiempo puede agotar los disponibles). Las versiones más nuevas de IIS han incorporado mecanismo de aislamiento de procesos para atacar esa debilidad
En el caso de los lenguajes interpretados, que se apoyan en tener un DLL ISAPI para su interpretación, como bien dices, hay un paso extra, ya que primero les toca traducir los comandos. La conclusión es que enviando el comando directamente a un ISAPI propio compilado, tiene que ser más rápido. Por ello, no entiendo porque tu duda al decir :
Cita:
|
Pero un lenguaje compilado, procesamiento directo? No tanto.
|
Ahora. en el caso de los CGI, la idea es que la respuesta a la petición la brinda un ejecutable. El ejecutable se carga en memoria cuando se recibe la petición y se descarga cuando esta termina. Ciertamente, en términos de seguridad es mejor esquema, ya que cada petición queda completamente aislada y sus recursos se liberan enseguida.
Sin embargo, en términos de efeciencia es muy pobre comparada con la solución anterior, ya que el consumo de recursos, aún con el apoyo del caché, es mucho mayor, especialmente con conexiones a bases de datos, ya que en cada carga se inicializa sesión. Por supuesto, depende de las capacidades del hardware disponible y del tamaño del sistema que se desee emplear. En sistemas pequeños y con un buen hardware de respaldo, no se notarán mayores diferencias.
En mi opinión, el CGI se justifica como alternativa segura. También, en el pasado, como un mecanismo más facil de depuración; pero, con las herramientas más modernas de Delphi 2007, no le veo mayor peso, ya que depurar los DLLs ISAPI es facil