¿Cómo puedo ejecutar código ineficiente solo en tiempo de compilación cuando uso mod_perl?

Question

He estado evaluando el rendimiento de un marco que estoy escribiendo en Perl y estoy recibiendo un 50% de disminución en las solicitudes por segundo sobre nuestra base de código existente (algunos aciertos son comprensibles, porque vamos desde el código de espagueti de procedimientos a un marco OOP MVC).

La aplicación se está ejecutando en mod_perl, y he agregado Moose y todo mi código de marco en el startup.pl script, que duplicó mis solicitudes por segundo. Estoy buscando mejorar aún más este número para acercarlo lo más posible a la cantidad existente. El argumento es que esta es una optimización prematura, pero hay un par de ineficiencias flagrantes que me gustaría solucionar y ver cómo afecta el rendimiento.

Al igual que la mayoría de los marcos, tengo un archivo de configuración y un despachador. La parte de configuración es manejada por Config::General, por lo que se requiere un poco de IO y análisis para obtener mi archivo de configuración cargado en la aplicación. ¡El problema más grande que veo aquí es que estoy haciendo esto por CADA PETICIÓN que entra!

Ejecutando Devel :: Dprof en mi aplicación apunta a Config :: General :: BEGIN y un grupo de módulos de IO relacionados como uno de los principales puntos lentos que no es Moose. Entonces, lo que me gustaría hacer, y lo que tiene más sentido en retrospectiva es aprovechar la persistencia de mod_perl y las cosas de compilación de startup.pl para hacer solo el trabajo de cargar en el archivo de configuración una vez, cuando el servidor se inicie.

El problema es que no estoy muy familiarizado con la forma en que esto funcionaría.

Actualmente cada proyecto tiene una clase de programa previo PerlHandler que es bastante delgado y se ve así:

use MyApp; 
MyApp->new(config_file => '/path/to/site.config')->run(); 

MyApp.pm hereda del módulo de Proyecto de marco, que tiene este código:

my $config = Config::General->new(
       -ConfigFile => $self->config_file, 
       -InterPolateVars => 1, 
      );  

$self->config({$config->getall}); 

Para hacer esto solo en tiempo de compilación, tanto mi bootstrap como los módulos base del Proyecto tendrán que cambiar (creo), pero no estoy seguro de qué cambios realizar y aún así mantener el código agradable y sin problemas. Puede alguien señalarme la dirección correcta?

ACTUALIZACIÓN

He probado el bloque BEGIN en cada enfoque módulo de proyecto según lo descrito por ysth en su respuesta. Así que ahora tengo:

package MyApp::bootstrap; 
use MyApp; 

my $config; 
BEGIN 
{ 
    $config = {Config::General->new(...)->getall};   
} 

sub handler { ..etc. 
    MyApp->new(config => $config)->run(); 

Este cambio rápido solo me dio un aumento50% en solicitudes por segundo, lo que confirma mi pensamiento de que el archivo de configuración fue un importante cuello de botella pena de fijación. La cifra de referencia en nuestra vieja máquina dev de crotchety es 60rps, y mi marco ha pasado de 30rps a 45rps con este cambio solo. Para aquellos que dicen que Moose es lento y tiene un tiempo de compilación alcanzado ... Obtuve el mismo (50%) aumento cuando compilé todo mi código Moose en la puesta en marcha como lo hice al precompilar mi archivo de configuración.

El único problema que tengo ahora es que esto viola el principio DRY ya que el mismo código Config :: General-> nuevo está en cada bloque BEGIN con solo la ruta al archivo de configuración que difiere. Tengo algunas estrategias diferentes para limitar esto, pero solo quería publicar los resultados de este cambio.

Answer 1

Suponiendo que sus aplicaciones no cambian la configuración en absoluto, se mueven en un bloque begin:

# this code goes at file scope 
my $config; 
BEGIN { 
    $config = { Config::General->new(...)->getall } 
} 

# when creating a new instance 
$self->config($config); 

Y asegúrese de que todos los módulos se compilan en startup.pl.

Puede obtener más elegante, y tener una clase singleton proporcionar el config hash, pero no es necesario.

Answer 2

que tenían los mismos problemas en un marco HTML :: Mason instalar, y se encontró que esto funcione bastante bien: En httpd.conf:

PerlRequire handler.pl 
<FilesMatch "\.mhtml$"> 
    SetHandler perl-script 
    PerlHandler YourModule::Mason 
</FilesMatch> 

En el archivo handler.pl, se definen todos sus elementos estáticos como su configuración, manejadores de base de datos, etc. Esto los define en el ámbito de YourModule :: Mason que se compila cuando se inicia el hilo de apache (los nuevos hilos obviamente tendrán una sobrecarga inherente). YourModule :: Mason tiene un método handler que maneja la solicitud.

Admitiré que puede haber algo de magia que esté sucediendo en HTML :: Mason que me está ayudando con esto, pero me funciona, ¿tal vez para ti?

Answer 3

Si puede hacer sus clases de Moose immutable, eso podría darle otro aumento de velocidad.

Answer 4

JackM tiene la idea correcta.

Al cargar todas sus clases y crear instancias de los objetos de nivel de aplicación (en su caso, la configuración) en el proceso de Apache " madre", usted no tiene que ellas compilar cada vez que un nuevo trabajador desova, ya que ya están disponibles y en la memoria. Los muy meticulosos entre nosotros agregan una línea de "uso" para cada módulo que su aplicación usa regularmente. Si no carga sus paquetes y módulos en el buque nodriza, cada trabajador no solo aprovechará la carga de rendimiento de cargar los módulos, sino que no obtendrá el beneficio de compartir la memoria que ofrecen los sistemas operativos modernos.

Es realmente la otra mitad de la diferencia entre mod_perl y CGI. La primera mitad es el perl-engine persistente de mod_perl frente al perl de reaparición de CGI para cada invocación.

Answer 5

Una forma común de acelerar tales cosas con pocos cambios es simplemente usar variables globales y el estado de caché en ellos entre invocaciones de un mismo proceso de Apache:

use vars qw ($config); 
# ... 
$config = Config::General->new(...)->getall 
    unless blessed($config); # add more suitable test here 

No es muy limpio y puede conducir a oscuras errores (aunque "my $ var" lleva a más en mi experiencia) y a veces se come mucha memoria, pero muchas declaraciones de inicialización costosas (repetidas) se pueden evitar de esta manera. La ventaja sobre el uso de BEGIN {}; solo el código es que puede volver a inicializarse en función de otros eventos sin necesidad de reiniciar Apache o matar su proceso (por ejemplo, incluyendo la marca de tiempo de un archivo en el disco en la prueba anterior).

Cuidado con las trampas sin embargo: an easy way to break in

Answer 6

de un módulo de import sub se ejecuta en tiempo de compilación, por lo que podría utilizar eso para reducir/eliminar la SECO de ysth's answer.

En el siguiente ejemplo usamos un método de importación para leer el archivo de configuración con los argumentos que se nos dan y luego insertamos esa configuración en el paquete de llamadas.

La advertencia de cualquier variable $config en el paquete de llamada va a quedar anulada por esto.

package Foo_Config; 
use English qw(-no_match_vars); 
sub import { 
    my ($self, @cfg) = @ARG; 
    my $call_pkg  = caller; 
    my $config  = {Config::General->new(@cfg)->getall}; 
    do{ # this will create the $config variable in the calling package. 
     no strict 'refs'; 
     ${$call_pkg . '::config'} = $config; 
    }; 
    return; 
} 

package MyApp; 
# will execute Foo_Config->import('/path/to/site.config') at compile time. 
use Foo_Config '/path/to/site.config';