doctrine2 - query - Intentando comprender e implementar Symfony 3 Caching para Framework y Doctrine

symfony force database

Question

Tenemos una aplicación en ejecución basada en Symfony 3.2 (comenzada con Symfony 2.3 en ese entonces) y Doctrine ORM 2.5 y es impresionante cómo han evolucionado las cosas.

Leí mucho sobre el nuevo componente Symfony Cache, los altibajos de APC y APCU, opcache, las solicitudes de extracción para chaflán en Symfony, etc. pero para ser sincero, esta vez me perdiste un poco.

Por lo tanto, le pido amablemente si me pueden ayudar en 1) comprender y 2) implementar el almacenamiento en caché para una aplicación "estándar" de Symfony / Doctrine en producción.

Prerrequisitos / Suposiciones

1) opcache debería estar habilitado y activo y almacenar en caché cualquier código byte relacionado.

2) Actualmente no tengo ningún requisito para almacenar en caché mi propio material de aplicación. Se trata del almacenamiento en caché de marcos como anotaciones, mapas de clases, validaciones, metadatos ORM, etc.

2) La mayoría de los desarrolladores no quieren tratar con más de un proveedor de almacenamiento en caché, por lo tanto, sean APCu, xcache, redis, memcache o cualquier otra cosa. Puede haber muy buenas razones para tener diferentes para diferentes tareas, pero ceñirse a uno para hacerlo simple.

Opciones de almacenamiento en caché en una aplicación Symfony / Doctrine "estándar" en modo prod

1) Carga de clase

Todavía tenemos ApcClassLoader en su lugar en app.php :

$loader = require __DIR__ . ''/../app/autoload.php'';
include_once __DIR__ . ''/../var/bootstrap.php.cache'';

$apcLoader = new ApcClassLoader(''arcsf2'', $loader);
$apcLoader->register(true);
$loader->unregister();

require_once __DIR__ . ''/../app/AppCache.php'';

$kernel = new AppKernel(''prod'', false);
$kernel->loadClassCache();
$kernel = new AppCache($kernel);

Solo hay dos opciones integradas de Symfony, según entiendo, ApcClassLoader y XcacheClassLoader. Entonces, esto podría estar contradiciendo el supuesto 2 anterior.

Pregunta:

¿Sigue siendo necesario / requerido / tener un rendimiento significativamente mejor para tener este caché de ClassLoaders en su lugar?

¿O es suficiente utilizar la aplicación estándar.php hoy en día?

$loader = require __DIR__.''/../app/autoload.php'';
include_once __DIR__.''/../var/bootstrap.php.cache'';

$kernel = new AppKernel(''prod'', false);
$kernel->loadClassCache();

2) Almacenamiento en memoria caché de validación

Aún tenemos esto en nuestro config_prod.yml :

framework:
validation:
    cache: validator.mapping.cache.doctrine.apc

Pregunta:

Para ser sincero, no tengo idea, si esto sigue siendo válido con Symfony 3.2 y el nuevo componente de caché. Y cómo cambiarlo a un proveedor de caché diferente si es necesario. ¿Cómo podría cambiarlo para que esté ''actualizado'' con Symfony 3.2 Cache?

3) Caché de Doctrine:

Más o menos la misma pregunta se aplica a la sección orm de doctrina en config_prod.yml :

doctrine:
orm:
    metadata_cache_driver: apc
    result_cache_driver: apc
    query_cache_driver: apc

Pregunta :

¿Todavía es el camino a seguir? Cómo cambiar este uso, el nuevo componente Symfony Cache, ¿se puede hacer de todos modos?

4) Nuevas opciones?

¿Y el nuevo? opciones? de configuración en config_prod.yml :

framework:
cache:
    app: cache.adapter.someProviderOrPool
    system: cache.adapter.someProviderOrPool

Pregunta :

¿Qué tipo de información se almacena en la caché aquí, por quién y de alguna manera esta reemplazando / extendiendo algunos de los temas anteriores?

En resumen:

Quiero básicamente cambiar todas las configuraciones de mi dispositivo para que sean compatibles con Symfony 3.2 y quiero usar redis para el almacenamiento en caché (reemplazando la aplicación) siempre que sea posible, pero no tengo ni idea de cómo y por dónde empezar.

****EDITAR****

También en este contexto, ¿cómo juegan Symfony Cache Component y DoctrineCacheBundle juntos? Reemplazando? ¿Sumando? ¿Sobre la base de? ¿Trabajando juntos? ¿Contradictorio? ¿No es comparable?

Answer 1

La documentación de rendimiento de Symfony está obsoleta. Lo hemos actualizado con otro commiter, pero la solicitud de extracción todavía está esperando su aprobación. Solo estoy copiando / pegando el nuevo documento aquí por ahora. Puede encontrar la Solicitud de extracción de GitHub aquí

Use el caché de código de byte OPcache

OPcache almacena los archivos compilados de PHP para evitar tener que recompilarlos para cada solicitud. Hay algunos cachés de códigos de bytes disponibles, pero a partir de PHP 5.5, PHP viene con OPcache incorporado. Para versiones anteriores, el caché de código de bytes más utilizado es APC.

Configure OPcache para un máximo rendimiento

La configuración predeterminada de OPcache no es adecuada para la aplicación Symfony, por lo que se recomienda cambiar estas configuraciones de la siguiente manera:

; php.ini

; maximum memory that OPcache can use to store compiled PHP files
opcache.memory_consumption=256M

; maximum number of files that can be stored in the cache
opcache.max_accelerated_files=20000

No verifique las marcas de tiempo de PHP

En los servidores de producción, los archivos PHP nunca deberían cambiar, a menos que se implemente una nueva versión de la aplicación. Sin embargo, OPcache comprueba de forma predeterminada si los archivos en caché han cambiado su contenido desde el almacenamiento en caché. Este control introduce algunos gastos generales que se pueden evitar de la siguiente manera:

; php.ini

; after each deploy, call `opcache_reset()` or restart the web server
; to empty the cache and regenerate the cached files. Otherwise you won''t
; see the updates made in the application
opcache.validate_timestamps=0

Nota

El OPcache es diferente para el servidor web y la consola de comandos. No puede borrar el caché del servidor web ejecutando algún comando en su terminal. Debe reiniciar el servidor web o llamar a la función opcache_reset () a través del servidor web (es decir, tener esto en un script que ejecuta en la web).

Configurar el caché realpath de PHP

Cuando una ruta relativa se transforma en su ruta real y absoluta, PHP almacena el resultado en caché para mejorar el rendimiento. La configuración predeterminada de este caché no es adecuada para aplicaciones que abren muchos archivos PHP, como Symfony. Se recomienda cambiar estas configuraciones de la siguiente manera:

; php.ini

; maximum memory allocated to store the results
realpath_cache_size=4096K

; save the results for 10 minutes (600 seconds)
realpath_cache_ttl=600

Configurar el caché realpath de PHP

PHP utiliza un caché interno para almacenar el resultado de la asignación de rutas de archivos a sus rutas de sistema de archivos reales y absolutas. Esto aumenta el rendimiento para aplicaciones como Symfony que abren muchos archivos PHP, especialmente en sistemas Windows.

Por defecto, PHP establece un realpath_cache_size de 16K que es demasiado bajo para Symfony. Considere actualizar este valor al menos a 4096K. Además, las rutas en caché solo se almacenan durante 120 segundos de forma predeterminada. Considere actualizar este valor también usando la opción realpath_cache_ttl :

; php.ini

realpath_cache_size=4096K
realpath_cache_ttl=600

Optimice el autocargador de Composer

El cargador de clases utilizado al desarrollar la aplicación está optimizado para encontrar clases nuevas y modificadas. En los servidores de producción, los archivos PHP nunca deberían cambiar, a menos que se implemente una nueva versión de la aplicación. Es por eso que puede usar la optimización del autocargador de Composer para escanear toda la aplicación una vez y crear un "mapa de clase", que es una gran variedad de ubicaciones de todas las clases y se almacena en vendor / composer / autoload_classmap.php .

Ejecute este comando para generar el mapa de clases en el momento de la instalación (y así hacer que forme parte de su proceso de implementación):

$ composer install --no-dev --optimize-autoloader --classmap-authoritative --apcu-autoloader

--no-dev Excluye las clases que solo se necesitan en el entorno de desarrollo (por ejemplo, pruebas).

--optimize-autoloader cada clase compatible con PSR-0 y PSR-4 utilizada en su aplicación.

--classmap-authoritative Impide que Composer escanee el sistema de archivos para las clases que no se encuentran en el mapa de clases.

--apcu-autoloader Necesita instalar la extensión PHP de APCu para usar esta opción. Cacheará el mapa de clase en APCu. Sin embargo, no generará el mapa de clases, por lo que siempre debe usarlo con --optimize-autoloader

Propina

Si su servidor de producción todavía usa la extensión PHP APC heredada en lugar de OPcache, instale el componente APCu Polyfill en su aplicación para habilitar la compatibilidad con las funciones PHP de APCu y desbloquee la compatibilidad con funciones avanzadas de Symfony, como el adaptador de caché APCu.

Nota

Al utilizar el autocargador APCu, si agrega nuevas clases, se encontrarán automáticamente y todo funcionará igual que antes (es decir, no hay razón para "borrar" la caché). Sin embargo, si cambia la ubicación de un espacio de nombre o prefijo en particular, deberá vaciar su caché APCu. De lo contrario, el autocargador seguirá mirando la ubicación anterior para todas las clases dentro de ese espacio de nombres.