¿Cómo reduzco el número de solicitudes redundantes con mod_perl correctamente?

Question

En un proyecto legado bastante grande, he refabricado varios módulos peludos en las clases de Moose. Cada uno de estos módulos requiere que el acceso a la base de datos (lazy) recupere sus atributos. Dado que esos objetos se usan bastante, quiero reducir el número de solicitudes redundantes, por ejemplo, para datos sin cambios.

Ahora, ¿cómo hago eso correctamente? Tengo varias alternativas:

1. implementar la caché en mis clases de los alces a través de un papel para almacenarlos en memcached con vencimiento de 5-10 minutos (probablemente no es demasiado difícil, pero difícil con los atributos lazy) actualización: KiokuDB probablemente podría ayudar aquí, tiene que leer acerca de los atributos
2. Migrar a DBIx::Class (hay que hacer de todos modos) e implementar el almacenamiento en caché en este nivel (DBIC probable que tome la mayor parte del dolor de distancia sólo por sí mismo)
3. de alguna manera hacer mis objetos persisten dentro del proceso mod_perl (no hay manera de hacer esto :()

¿Cómo harías esto y qué consideras de una manera sensata? ¿Se prefieren los datos de almacenamiento en caché en el objeto o en el nivel de ORM?

Answer 1

Dado que ya va a hacer DBIC de todos modos, tendría sentido dejar que este cambio lo solucione. Tendría menos sentido rodar el suyo propio y luego implementar DBIC, dando a sus mantenedores una pausa cuando descubran que están usando DBIC pero con almacenamiento en caché interno ... "por alguna razón".

Las únicas razones para no hacer esto serían (1) si realmente necesita ese rendimiento ahora y no tiene tiempo para esperar los cambios de DBIC, ya que imagino que será bastante extenso. O (2), si no está seguro de si realmente se va a mudar a DBIC. Si no lo ha investigado y está haciendo una gran cantidad de SQL personalizado en lugar de CRUD básico, podría terminar siendo un retorno de la inversión muy pequeño.

Answer 2

La respuesta corta al # 3 es: No use 'mi'. Es posible hacer algo como:

use vars qw($object); 
# OR post perl5.6: 
# our ($object); 

# create your object if it doesn't already exist 
$object ||= create_object; 

# Maybe reload some attributes if they have expired. 
$object->check_expires; 

Los objetos creados como esto dentro de su controlador sólo será compartida dentro de cada niño Apache, que está bien si vuelve a cargar los datos de cada 5-10 minutos. Todos los módulos y objetos de solo lectura deben cargarse en una secuencia de comandos PerlPostConfigRequire para que se compartan en todos los elementos secundarios.