En esta pequeña nota les voy a explicar que son, para que sirven y cual es la forma apropiada de usarlos para mejorar la performance en un entorno basado en Apache. Los «Op Code» Caches son modulos de cache que se agregan a una configuración de server web y que permiten pre-compilar codigo PHP que en este caso el lector solicita al servidor y que permite en definitiva acelerar el proceso. Como todos saben, PHP es un lenguaje de ejecución en tiempo real, esto implica que cada proceso que el cliente solicita debe ser compilado en tiempo real para entregar codigo limpio en formato html al cliente.
Porque Op Code Caches:
Debido a que el codigo PHP que uno solicita a cualquier servidor cuando se encuentra navegando en una web debe ser previamente compilado para ofrecer un html resultante por el mismo servidor, esto eleva la carga del mismo, en un escenario con pocas visitas, no es un problema, pero a medida que la web recibe un afluente cada vez mayor de visitas, puede convertirse en un serio problema, sobre todo en el uso de CPU. Los Op-Code caches trabajan pre-compilando los archivos php mas usados por los clientes y manteniendo una «copia» pre-compilada en su memoria, de esta forma, cuando el proximo cliente solicite ese archivo php, no consumirá tiempo de cpu y otorgará una copia pre-compilada del mismo desde su espacio de memoria.
Variantes:
Tenemos varios op-code caches en el mercado, todos gratuitos por supuesto y todos igual de buenos, pero con ligeras diferencias. El mas conocido a estas alturas es el eaccelerator, seguido de cerca por el xcache y el APC.
Eaccelerator:
eaccelerator es el mas antiguo de todos y el mas desactualizado, debido a que el desarrollador original no agregó demasiadas mejoras en los ultimos lanzamientos y por el contrario, ha removido codigo que le brindaba ventajas sobre los demas, quizas por razones de inestabilidad, lo cierto es que eaccelerator es un opcode cache con menos opciones de configuración pero que funciona bien, no he escuchado ningun caso de fallas y nosotros usamos el mismo en todo el dominio TecnoGaming y como podrán ver, no presenta problemas, es extremadamente estable y la administración de memoria ram es extremadamente precisa, será por esto que es uno de los mas usados incluso estando algo desactualizado para estos tiempos.
XCache:
xcache es un opcode algo mas completo que eaccelerator pero que ha presentado en algunos casos problemas de estabilidad, nosotros mismos lo hemos probado y suele muy rara vez presentar problemas, tuvo algunos incidentes de fugas de memoria que ya fueron solucionados pero no tiene la fama intachable que el eaccelerator posee en cuanto a estabilidad. Es muy eficiente en lo que a performance se refiere y tiene mayores opciones de configuración que eaccelerator.
APC:
Lejos uno de los mas completos de los tres, el APC goza de ciertas ventajas, entre ellas un panel informativo superior al que usa el eaccelerator, un mayor detalle de sus acciones, muy buena administración de los recursos y la principal ventaja de que es el OpCode Cache seleccionado por PHP para ser incluído en su próxima versión, por lo tanto, es muy probable que en la proxima PHP6, el APC sea parte del mismo y no necesitemos instalarlo a parte como ocurre ahora, esto le brindará mayor solidez y un nivel de estandarización que hoy en dia todavia no posee.
Limitaciones:
Es indudable que utilizar un op-code cache es escencial para mejorar la performance de cualquier web, sobre todo si utilizan sistemas complejos como wordpress que hace uso intensivo de codigo PHP, aunque la aseveración es igual de valida para todos los demas sistemas, incluido joomla. Pero que limitaciónes hay en cuanto a su uso?. Primero y principal, la cantidad de memoria necesaria. Todos los op-code caches vienen configurados por defecto para usar 32mb, este es el espacio de memoria compartido que pueden usar todos los procesos bajo linux, establecido por su parametro de kernel shmmax que se encuentre configurado en 32mb., pero esta cantidad es mas que insuficiente para proveer un cache op-code exitoso en sitios de mediana cantidad de trafico, mas memoria es requerida, esto implica modificar el shmmax en el kernel de linux, reiniciar el servidor y configurar mayor cantidad de memoria en el op-code cache. Otra limitación presente en estos caches es la fragmentación, este es un tema serio que requiere mucha optimización por parte del administrador del servidor, puesto que al almacenar información, como todo cache, suelen quedar bloques vacios y fragmentos cuando los codigos dejan de ser usados o son reemplazados por nuevas versiones del mismo archivo, esto hace que se produzca fragmentación, sobre todo cuando no hay espacio suficiente contiguo para albergar un archivo php necesario, lo cual hace que el mismo quede afuera. Todos los opcode caches tienen formas de solucionar este dilema y todos recurren a limpiarse luego de cierto tiempo, cuando detectan que la fragmentación es muy grande. El mas conocido por hacer esto de manera intermitente es el APC, que limpia su memoria de manera extremadamente regular si la cantidad de memoria es insuficiente o si su fragmentación es muy grande. El problema de la fragmentación se resuelve a mas memoria libre se le asigna al op-code cache, pero mas de 128mb ya requiere un servidor con mas de 1.5gb de RAM y esto incurre en un gasto adicional de nuestra parte, optimizar este tipo de caches es escencial para sacarle el maximo provecho.
La ultima limitación reside en el modo de operación del servidor web y PHP. Los opcode caches no pueden ser activados si el servidor esta corriendo en modo DSO. Para el PHP los opcode caches admiten correr con los modos: CGI, FastCGI y Mod-PHP pero tienen algunos problemas con el modo suPHP por lo tanto hay que tomar los recaudos de saber que cumplimos con la compatibilidad necesaria antes de intentar usarlos. La principal limitacion de los opcode caches se da trabajando en modo FastCGI, como veremos mas adelante, FastCGI es un interprete que se coloca de manera paralela al Apache, escuchando generalmente en el puerto 9000, FastCGI abre un proceso nuevo por cada web/usuario exista en nuestro servidor, esto trae serios problemas a la hora de que un op-code cache trabaje adecuadamente. Al no poder compartir el espacio de trabajo, cada proceso utiliza una porción distinta del cache y por lo tanto, cuando un op-code cache trabaja en una entorno con FastCGI esto hace que toneladas de espacio se desperdicien cacheando objetos repetidos, esto incrementa notablemente el uso de RAM y degrada la performance. Nosotros en lo particular no recomendamos utilizar un Op-Code cache en un entorno FastCGI a no ser que tengamos mucha RAM disponible, en este caso es mas prudente usar el modo mod-PHP que le permitirá sacar mucho mas ventaja al op-code cache.
Cual es el Mejor:
No podríamos titular a uno como el vencedor victorioso sobre los demas puestos que todos tienen sus cosas buenas y malas, pero en nuestra selección natural, despues de haber probado todos, el premio a estabilidad se lo lleva el eaccelerator, mientras que el APC es sin dudas uno de los mas completos y que funciona igual de bien que eaccelerator, el xcache por su cuenta nos ha traido muchos problemas tan solo a las horas de haber sido activado por lo tanto nosotros no lo recomendamos para ambientes donde la estabilidad es indispensable, quizas existe una forma de afinar al máximo su configuración para que no traiga problemas pero lo cierto es que tanto el APC como el eaccelerator funcionan «out of the box» sin requerir conocimientos avanzados y lo hacen igual de bien que el xcache.
