¿Puedo usar Apache mod_proxy como un grupo de conexiones, bajo Prefork MPM?

Question

Resumen/de Quesiton:

He Apache corriendo con Prefork MPM, corriendo php. Intento usar Apache mod_proxy para crear un proxy inverso al que pueda redireccionar mis solicitudes, de modo que pueda usar Apache para hacer la agrupación de conexiones. Ejemplo: impl

en httpd.conf:

SSLProxyEngine On 
ProxyPass /test_proxy/ https://destination.server.com/ min=1 keepalive=On ttl=120 

pero cuando corro mi prueba, que es el siguiente comando en un bucle:

curl -G 'http://localhost:80/test_proxy/testpage' 

no parece que volver usa las conexiones.

Después de leer un poco más, parece que no estoy obteniendo la funcionalidad del conjunto de conexiones porque estoy usando Prefork MPM en lugar de Worker MPM. Así que cada vez que hago una solicitud al proxy, se activa un nuevo proceso con su propio grupo de conexiones (del tamaño uno), en lugar de usar el único trabajador que mantiene su propio grupo. ¿Es esa interpretación correcta?

---

información Antecedentes:

Hay un servidor externo que hago peticiones para, a través de HTTPS, para cada página golpeado en un sitio que corro.

Negociar el protocolo de enlace SSL es cada vez más costoso, porque utilizo php y no parece ser compatible con la agrupación de conexiones: si recibo 300 solicitudes de página a mi sitio, tienen que realizar 300 protocolos SSL al servidor externo, porque las conexiones se cierran después de que cada script termina de ejecutarse.

Estoy intentando usar un proxy inverso bajo Apache para funcionar como un grupo de conexiones, para persistir las conexiones a través de los procesos de php, por lo que no tengo que hacer el protocolo de enlace SSL con tanta frecuencia.

Las fuentes que me dio esta idea:

• http://httpd.apache.org/docs/current/mod/mod_proxy.html
• http://geeksnotes.livejournal.com/21264.html

Answer 1

Prefork todavía se pueden agrupar 1 conexión por servidor back-end por proceso.

Prefork no crea necesariamente un nuevo proceso para cada solicitud de frontend, los procesos del servidor se "agrupan" ellos mismos y el comportamiento depende, p. MinSpareServers/MaxSpareServers y amigos.

Para maximizar la frecuencia con la que un proceso de preformado tendrá una conexión de fondo para usted, evite los servidores de máxima o baja respuesta o servidores de minutos muy altos, ya que estos procesos "nuevos" aceptarán nuevas conexiones.

Puede registrar% P en su directiva LogFormat para hacerse una idea de la frecuencia con la que se reutilizan los procesos.

Answer 2

En primer lugar, su método de prueba no puede demostrar la agrupación de conexiones, ya que para cada llamada, un cliente curl nace y luego muere. Como las personas muertas no hablan mucho, un proceso muerto no puede mantener viva una conexión.

Tiene clientes que molestan a su servidor proxy.

Client ====== (A) =====> ProxyServer 

Vamos a llamar a esta conexión A. Su servidor proxy no hace nada, es sólo un espectáculo fuera. El servidor guapo y trabajador es tan humilde que se esconde detrás.

Client ====== (A) =====> ProxyServer ====== (B) =====> WebServer 

Aquí, si no estoy equivocado, la conexión segura es A, no B, ¿verdad?

Repitiendo mi primer punto, en su prueba, está creando un cliente diferente para cada solicitud. Cada cliente necesita una conexión separada. La conexión es algo que ocurre entre al menos dos partes. Un lado se va y la conexión se pierde.

De acuerdo, olvidemos curl ahora y miremos juntos lo que realmente queremos hacer.

Queremos tener SSL en A y queremos que el lado A del tráfico sea lo más rápido posible. Para este objetivo, ya hemos separado el lado B, por lo que A no hará que A sea aún más lento, ¿verdad?

¿Interconexión de conexiones? No existe una agrupación de conexiones en A. Cada cliente va y viene haciendo mucho ruido. Lo único que puede ayudarlo a reducir este ruido es "Keep-Alive", lo que significa que mantiene la conexión activa desde un cliente durante un breve período de tiempo, por lo que este mismo cliente puede solicitar otros archivos que esta solicitud requerirá . Cuando terminemos, habremos terminado.

Para las conexiones en B, las conexiones se agruparán; pero esto no le traerá ningún rendimiento ya que en la configuración de un servidor no tenía esta parte de la producción de ruido.

¿Cómo ayudamos a que este sistema funcione más rápido?

Si estos dos servidores están en la misma máquina, deberíamos deshacernos del servidor de demostración y continuar con nuestro servidor web. Agrega mucho trabajo innecesario al sistema.

Si se trata de máquinas separadas, entonces está siendo amable con el servidor web al tomar al menos encyrption (para ssl) la carga de este pobre tipo. Sin embargo, puedes ser aún más agradable.

Si desea continuar con Apache, cambie a mpm_worker desde mpm_prefork. En caso de más de 300 solicitudes simultáneas, esto funcionará mucho mejor. Realmente no tengo idea de la capacidad de tu hardware; pero si manejar 300 solicitudes es difícil, creo que este pequeño cambio ayudará mucho a su sistema.

Si desea tener un sistema aún más liviano, considere nginx como una alternativa a Apache. Es muy easy to setup para trabajar con PHP y tendrá un mejor rendimiento.

Aparte del lado frontal de las cosas, también considere consultar su servidor de base de datos. La agrupación de conexiones hará una gran diferencia aquí. Asegúrese de que su instalación de PHP esté configurada para reutilizar las conexiones a la base de datos.

Además, si usted es anfitrión de archivos estáticos en el mismo sistema, a continuación, pasar a cabo ya sea en otro servidor web o hacerlo aún mejor moviendo archivos estáticos a un sistema de nubes con CDN como el de S3 + CloudFront o Rackspace's CloudFiles AWS. Incluso sin CloudFront, S3 te hará feliz. La solución de Rackspace viene con Akamai!

Sacar archivos estáticos hará que su servidor web "oh qué pasó, ¿qué es este silencio? Ohhh cielo!" ya que mencionó que este es un sitio web y las páginas web tienen muchos archivos estáticos para cada página html generada dinámicamente la mayor parte del tiempo.

Espero que pueda salvar al pobre hombre del trabajo asesino.

Answer 3

El problema en mi caso fue que la conexión de la agrupación entre el proxy inverso y el servidor backend no se llevaba a cabo debido a Apache del Servidor de fondo que cerraba la conexión SSL al final de cada solicitud HTTPS.

El backend servidor Apache estaba haciendo esto los pisos más altos de la siguiente directiva estar presente en el httpd.conf:

SetEnvIf User-Agent ".*MSIE.*" nokeepalive ssl-unclean-shutdown 

Esta directiva no tiene sentido cuando el servidor back-end está conectado a través de un proxy inverso y esto puede ser eliminado desde la configuración del servidor back-end.