Si trabajáis en PHP, ya conocéis APC, así que vamos a revisar algunas configuraciones y prácticas que hacemos en Emagister y que nos han reportado buenos resultados. (Si no fuera el caso, os recomendamos alguna de las referencias al final de este artículo)

Utiliza el script que trae APC (apc.php) para diagnosticar problemas

Para poder ver lo que está pasando con vuestro APC, la manera más sencilla es apc.php, un script incluido cuando te descargas el paquete de apc, si no es el caso, no os costará encontrarlo por internet. Fácil, cómodo y sencillo.

Atención al “Cache full count”

Éste indicador mide el número de veces que la caché estaba llena cuando fuimos a escribir algo, lo que significa que muchas entradas están saliendo para que otras nuevas entren. La manera de mantenerlo a 0 es aumentando la cantidad de memoria con “apc.shm_size”. Prestad atención, llegará un momento que por más que aumentéis la memoria, no ganaréis rendimiento, así que haced un par de pruebas para encontrar vuestro punto ideal.

Scripts demasiado grandes (> 1Mb)

Cuidado con scripts que sean más grandes que “apc.max_file_size”, no se cachearán! “Veeeeeeenga”, pensaréis, “quién va a tener scripts más grandes de 1Mb??”, pues las nuevas políticas de autoloading que traen los framewoks (Symfony2, ZF2, etc.) se basan en ficheros que mapean las clases del código y su ubicación en disco, estos ficheros, pueden llegar a alcanzar estos límites. La solución puede ser particionar o refactorizar archivos.

Comprobación de que los ficheros PHP se hayan modificados

Para facilitar la vida APC, descartará cualquier script cacheado si la fecha de modificación del archivo es diferente a la versión cacheada. Esta comprobación se hace con cada petición a un script, por lo que si no cambian frecuentemente, lo adecuado es setear “apc.stat = 0″ para evitar esta comprobación.

El problema es que tendremos que forzar el flush de la cache o un refrescar nuestro apache para reiniciar la memoria de APC, un proceso que podéis incluir en vuestro script de subida.

Locking

Hay varias políticas para gestionar los locks: pthread mutex Locks locking (de serie) y spin Locks locking, 50% más rápida que la anterior pero experimental (para activarla, “phpize”. No la tenemos en Emagister pero sí en algunos proyectos personales funcionando sin problemas)

Utilizando igbinary como serializer

Cuando se guadan datos como una array, un objeto, etc. en un lugar no PHP nativo como memcache, apc, gearman, etc. es necesario serializar dichos datos. Existe una alternativa al serializador por defecto que trae PHP que es igbinary. Para hacerlo trabajar con APC sólo hay que setear “apc.serializer=igbinary” en nuestro apc.ini.

Sin compresión

Para optimizar el rendimiento de igbinary, y si el espacio no es un problema, lo mejor es que serialize pero no aplique ningún criterio de compresión. Para ello, “igbinary.compact_strings=Off”

Conclusión

Hay cosas que cuestan tan poco…

1. Aumentar el espacio de memoria para que el “Cache full count” sea 0.

2. Utilizad igbinary para acelerar el procese de serialización y deserialización (a parte lo podréis utilizar en código normal con igbinary_serialize y igbinary_unserialize, con sistemas de colas, por ejemplo).

3. Setead apc.stat a 0 en producción y forzar un reload o un flush del apc después de que algún fichero cambie (con una subida, por ejemplo)

Material extra

http://prezi.com/re8rsdjmpkko/oscon-09-high-performance-apc/

http://www.slideshare.net/vortexau/improving-php-application-performance-with-apc-presentation

http://www.php.net/manual/en/apc.configuration.php

http://talks.php.net/show/froscon08

http://phpolyk.wordpress.com/2011/08/28/igbinary-the-new-php-serializer/

 

Leave a reply

 

Your email address will not be published.