Hola. Yo', usando Gentoo Linux. parece que no puedo emerger/instalar mod_perl con un apache2 con subprocesos, así que me gustaría saber cuáles son las ventajas y desventajas de usar el módulo de trabajo de apache2 con cgi-perl y usar el módulo prefork de apache2 con mod_perl.
¿Qué es más rápido? ¿Qué requiere menos recursos? En cuanto a la seguridad, ¿hay alguna diferencia?
¡gracias!
Respuesta1
En Linux, use Apache prefork con mod_perl. Threaded MPM es una gran ventaja para los usuarios de Win32, donde la creación de procesos es costosa. En Linux, fork() es una llamada bastante económica. Sin embargo, los desarrolladores de Mod_perl2 han hecho un gran esfuerzo para hacer que mod_perl2 funcione con subprocesos apache2 +, pero el modelo de subproceso en perl consume un poco de memoria.
Desarrollamos una gran aplicación mod_perl, y si tuviéramos que recrearla hoy, probablemente recomendaría uno de los diversos marcos y usaría FastCGI oPSGI. El uso de FCGI o un marco con capacidades nativas de PSGI/FCGI le permite elegir entre interfaces (nginx, lighttpd, apache2). Puede hacer chroot en su aplicación y reducir sus privilegios (solo necesita un socket para comunicarse con su interfaz). Si haces que tu aplicación use mod_perl2, estás prácticamente casado con Apache2.
Respuesta2
En mi humilde opinión, prefork+mod_per sería mucho más rápido, pero preguntar en la lista de correo de mod_perl le daría una respuesta más exacta
Respuesta3
Modperl es el adaptador perfecto para Catalyst, de la misma manera que Modpython y Modwsgi lo son para Django, y modphp es para Cakephp, mientras que Modruby se debate como mejor o peor que cgi, fcgi y (Modrails/Modpassenger/Modlocomotive) son para Rails. especialmente cuando se usa el modo de subprocesos (pero existen Modrake y el servidor de aplicaciones Mongrel como alternativas). Para evitar las desventajas y obtener sólo ventajas, utilice siempre el modo bifurcado. Estoy usando referencia solo a mvc de otros lenguajes de programación inspirados en Rails: es decir, Catalyst, Django, Cakephp y Rails.
En mi opinión, el modo mpm-itk-mode multifork es el mejor, seguido del modo mpm-event-mode multiproceso, luego viene el modo mpm-prefork-mode de un solo subproceso y, por último, viene el modo mpm-worker-mode de un solo subproceso.
Descubrí que para algunos lenguajes de programación, sus respectivos adaptadores apache2, como mod-php y mod-tcl, se ejecutan específicamente solo en el modo prefork y ni siquiera en el modo itk, mientras que mod-ruby todavía está solo en linux-apache2 y aún no. conviértalo en windows-apache2.
Pero, afortunadamente, mode-perl, mod-python y mod-ruby son lo suficientemente versátiles y pueden ejecutarse en los cuatro modos: modo libapache-mpm-worker, modo libapache-mpm-prefork, modo libapache-mpm-event. modo y modo libapache-mpm-itk. Esta es una buena noticia para los usuarios de Perl, Python y Ruby, pero por supuesto, incluso en el caso de los tres adaptadores, el modo bifurcado es más rápido, más versátil y libre de conflictos que el modo subproceso. Y una cosa es segura: todos estos adaptadores están diseñados para funcionar más rápido que cgi, y posiblemente tan rápido como fcgi (fastcgi).
Utilizo el modo itk (multifork), incluso si eso significa que me faltarán algunos softwares que requieren el modo prefork (una sola bifurcación).
Siempre había preferido el modo itk en Ubuntu y nunca opté por instalar aplicaciones que requieran el modo prefork como requisito previo. Algunas distribuciones como Sabayon, que es del tipo Gentoo, instalan apache2 en modo trabajador de forma predeterminada. Pero esto siempre podemos cambiar editando el archivo de configuración del sistema Apache y descomentando las líneas que contienenitk(y comentar las líneas paraobrero) seguido de recompilar y reiniciar apache2. Entonces, lo que sea que se aplique a Sabayon debería ser válido también para Gentoo. Sabayon y Gentoo instalan todos los softwares dependientes de prefork o de trabajadores, pero mientras los configuran, solo deben ejecutarse aquellos cuya dependencia cumple el sistema.
Los que se ven muy afectados son algunos de los marcos basados en PHP (requeridos para los sistemas de gestión de contenidos) que no se ejecutan. El único marco php que puede ejecutarse en modo itk, evento (y tal vez trabajador) es cake-php, que desafortunadamente muy pocos usan. Creo que incluso el marco horde (php) más conocido también debería funcionar.
Otra prueba de que los hilos son peores que las bifurcaciones es observar el número de conflictos que dos o más adaptadores de servidor web tienen entre sí y con el sistema, como vemos en Windows.
En el caso de Windows, Apache2 se configura con el modo de trabajo, ya que los modos prefork e itk no son posibles, pero el modo de evento debería ser muy posible. Por lo tanto, cambiar al modo de evento apache2 (multiproceso) debería resolver la mayoría de los problemas. Pero apache2 es muy flexible y personalizable para modperl (y por lo tanto perl-catalyst mvc), modpython (y por lo tanto django mvc), pero windows-modruby aún no es estable, su equivalente se conoce como modpassenger (modpassenger -- linux, modrails -- windows, locomotora - macosx) existen en abyss-webserver o lighttpd-webserver (y por lo tanto en Rails MVC).
La precaución es: si el sistema es Windows, antes de instalar MVC de Perl/Python/Ruby/PHP/Tcl, asegúrese de que todo esté configurado solo con un único servidor web, ya sea apache2 o lighttpd o tal vez cherokee. Si tiene la intención de utilizar Rails con abyss, modrails, asegúrese de que la configuración drupal/jhoomla con wamp, modphp no esté presente; de lo contrario, a veces el shell de Windows predeterminado de Windows XP puede fallar (aún puede recuperarlo usando Windows XP con alternativas). shells como reactos-shell, emerge-desktop, Sharp-enviro, bblean-blackbox, etc. con administradores de archivos alternativos como ros-explorer, cubic-explorer, ultra-explorer, etc., siempre que a cualquier usuario no le importe adaptarse. y usando el mismo sistema operativo con un shell de escritorio y un administrador de archivos de aspecto diferente).
En Windows, los modrails entran en conflicto con modphp (hasta que esté disponible un modruby estable), y el windows-desktop-shell basado en asp (entorno de modelo de objetos de red de Windows) solo puede contener uno a la vez, mientras que los shells alternativos escritos en bloques de código (reactos y emerge-desktop) no fallan, mientras que los escritos en Delphi (sharp-enviro) fallan parcialmente, pero una nueva versión de Lazarus de Sharp-enviro no debería fallar.
Por lo tanto, una de las razones por las que la tecnología web de Linux es mucho más variada y aún así exitosa se debe a las ventajas del modo bifurcado sobre el modo subproceso. La tecnología web de Windows todavía gira en general entre menos jugadores y algunas pocas tecnologías de código abierto después de trabajar mucho y duro.
Respuesta4
Solo algo de información adicional, simplemente descartamos mod_perl en Win32 y cambiamos a PSGI usando Plack. Hay una capa de compatibilidad para CGI::Application que funciona muy bien para nosotros. Catalyst también está cambiando/ha cambiado a PSGI.