• Puede ser utilizada como una API de cache para almacenar objetos y variables de PHP.
• Tiene la opción de configurarse como Session Handler de PHP con persistencia en disco.

Entre las características que posee esta extensión estan:

• Cache del bytecode de PHP en memoria, agilizando el tiempo de respuesta al no tener que parsear completamente los scripts PHP, lo cual reduce tambien el I/O overhead.
• Debido a que la persistencia de los elementos en cache es en disco, situaciones como un Reciclado de los application pools no afectan en el cache ya creado.
• Soporta las notificaciones de cambio de archivos, permitiendo refrescar los bytecodes en cache.
• Cuenta con funciones de PHP para conocer el estado del cache.

Creo que es una buena alternativa a utilizar en IIS para mejorar el performance de nuestras aplicaciones en PHP reduciendo el tiempo de interpretación de los scripts.

Para mayores detalles de uso podemos consultar el Manual de PHP sobre Windows Cache y para otros recursos sobre la extensión pueden consultar el blog de RuslanY con el post original.

Algunos links sobre Session State y la opción de SQL Server Session Mode

Overview en CodePoject

How-To de Microsoft Support

Fast, Scalable, and Secure Session State Management for Your Web Applications

En ocasiones, al cambiar de servidor dado a la distribución que realiza un load balancer, la aplicación parecía no poder obtener la información almacenada en sesión y por ende no poder continuar con el proceso que debía desarrollar. Al momento de revisar la base de datos de sesión pudimos percatarnos que habían 2 tuplas para una misma ASP.NetSessionId

Query: select * from ASPStateTempSessions where SessionId like '%piltae45debwl355ek3v0545%'

Y cómo es esto? Ok, resulta que el SessionId que utilizamos en nuestra aplicación no es lo único que se utiliza como llave en la tabla de SQL ya que está formada por:

Session Id + Application Id

(ver mas info acá: Session State Providers)

Resultó entonces que por cada servidor nos estaba generando una tupla en nuestro storage de sesión, la primera con la información que habíamos almacenado y la segunda como una nueva sesión totalmente vacía. Esto debido a que a cada webserver le estaba asignando un diferente Application Id.

Me dirán por ahí que esto no debía suceder… también hay un trasfondo relacionado con la aplicación que casualmente permite esto, sin embargo esto lo dejamos para otro post

Solución:

Debemos irnos a cada uno de los webservers del WebGarden y en cada uno debemos definir el “ID” del website. Para ello debemos colocarnos en “Sites”

Dar click derecho y en “Manage Web Site” seleccionamos la opción “Advanced Settings”

y finalmente nos aseguramos que el Website en cada uno de los Web Servers de nuestro WebGarden tenga el mismo ID

Reiniciamos los IIS para que todo camine en orden y voila!