Tres modos de apache-httpd
Nuevo módulo:
mod_proxy_fcgi (proporciona proxy fcgi)
mod_ratelimit (limita el ancho de banda del usuario)
mod_request (Solicitud módulo, solicitudes de filtro)
mod_remoteip (coincidir con la dirección IP del cliente)
El control de acceso basado en IP se ha modificado y ya no admite los mecanismos de permitir, denegar y ordenar, pero está unificado Usando require
También se agregan las siguientes funciones nuevas
1. Admite la carga de MPM en tiempo de ejecución; sin embargo, para habilitar esta función, estas tres funciones deben habilitarse durante la compilación y la instalación;
p>
--enable-mpms-shared=all --with-mpm=event
2. Eventos de soporte
3. Soporte asíncrono lectura y escritura
4. Especificar el nivel de registro de cada módulo y cada directorio
5. Mejorar el analizador de expresiones
6. Configurar a pedido:
7. Tiempo de espera de mantenimiento de vida de milisegundos
8. Los hosts virtuales basados en FQDN ya no requieren la directiva NameVirtualHost
9. Admite el uso de variables personalizadas
HTTPd puede agregar muchos módulos durante el proceso de instalación
Análisis de módulos relacionados:
--enable-so: admite el disfrute dinámico de los módulos (es decir, activar la compatibilidad con DSO)
--enable-rewrite: admite reescritura de URL
--enable-ssl: admite reescritura de URL
-- enable-ssl: Soporte ssl
--with-ssl=/usr/local/openssl:Especificar dónde está instalado ssl
--enable-cgi:Habilitar cgi
- -enable- cgid: MPM que usa eventos o trabajadores debe habilitar cgid
--enable-modules=most: especifica explícitamente los módulos que se compilarán estáticamente en el binario httpd,
Bloques
--enable-mpms-shared=all: habilite todos los modos admitidos de MPM para instalar eventos, trabajadores y preforks de forma modular y en httpd.conf Configurar el modo a utilizar.
--with-mpm=event: especifica el modo mpm habilitado. De forma predeterminada, el modo enevt se usa en versiones anteriores de Apache 2.0.
De manera predeterminada, prefork se usa en 2.2. Los trabajadores se utilizan en la versión 2.4 y los eventos se utilizan en la versión 2.4.
--with-pcre=/usr/local/pcre:Soporte pcre
--with-z=/usr/local/zlib:Usar biblioteca de compresión zlib
--with-apr=/usr/local/apr: Especifique la ruta de instalación de apr
--with-apr-util=/usr/local/apr-util: Especifique la ruta de instalación de apr -util Path
--enable-expires: habilite "Expires:" y "Cache-Control:" para controlar HTTP a través del archivo de configuración.
"Control:" encabezado, que proporciona la configuración de caché del navegador del cliente para imágenes del sitio web, js, css y otro contenido. Esta es una de las opciones
importantes para ajustar Apache.
--enable-deflate: brinda soporte para la codificación de transferencia comprimida de contenido, generalmente html, js, css y otro contenido en un sitio web. Utilice este parámetro para aumentar la velocidad de transferencia y mejorar la experiencia del visitante. En un entorno de producción, esta es una de las opciones más importantes para ajustar Apache
.
Optimice la configuración de Apache:
El entorno de hardware en el que se ejecuta Apache tiene el mayor impacto en el rendimiento. Incluso si el hardware no se puede actualizar, es mejor proporcionar un host independiente para Apache. . para evitar interferencias de otras aplicaciones. Entre los indicadores de hardware, el indicador que tiene mayor impacto en el rendimiento es la memoria. Para contenido estático (imágenes, archivos javascript, archivos css, etc.), determina cuánto contenido
Apache puede almacenar en caché. Cuanto más contenido en caché, mayores serán las posibilidades de leerlo en el disco duro. menos, por lo que una gran cantidad de memoria puede mejorar significativamente la velocidad de los sitios web estáticos
; para los sitios web dinámicos y de alta carga, es mejor equiparlos con un host separado para evitar interferencias de otras aplicaciones. Para sitios web dinámicos de alta carga, cada solicitud debe guardarse durante un período de tiempo adicional. El módulo mpm de Apache derivará el proceso o subproceso correspondiente para cada solicitud, y la cantidad de procesos o subprocesos está relacionada. El consumo de memoria es aproximadamente proporcional
, por lo que aumentar la memoria también es extremadamente beneficioso para mejorar la carga y la velocidad de ejecución de sitios web dinámicos
En segundo lugar, la velocidad del disco duro, especialmente los sitios web estáticos. , Apache continúa leyendo archivos y enviando las solicitudes correspondientes
El disco duro se lee y escribe con mucha frecuencia. Los sitios web dinámicos también cargan constantemente programas de sitios web (php, etc.) y solicitudes de lectura
p>un archivo es Se requiere un disco duro. ), una solicitud de lectura
puede incluso procesar una docena de archivos para completarse, por lo que aumentar la velocidad y la calidad del disco duro tanto como sea posible es una buena manera de mejorar
el rendimiento de Apache. .
Por lo tanto, maximizar la velocidad y la calidad de su disco duro tiene implicaciones positivas para mejorar el rendimiento de Apache.
Por último, está la CPU y la red. La CPU afecta la rapidez con la que se ejecutan los programas de red y la red afecta el tráfico.
Cómo funciona Apache:
El servidor HTTP Apache está diseñado para ser un servidor potente y flexible que puede funcionar en múltiples plataformas y en diferentes entornos
. Este diseño modular se denomina módulo multiprocesamiento (MPM), también conocido como modo de operación.
Modo pre-fork (un modo sin subprocesos):
Su principal método de trabajo es: cuando se inicia el servidor Apache, el módulo mpm_prefork creará previamente varios procesos secundarios (predeterminado
es 5), cada proceso hijo tiene solo un hilo. Al recibir una solicitud del cliente, el módulo mpm_prefork enviará la solicitud del cliente al módulo mpm_prefork.
Después de recibir la solicitud del cliente, el módulo mpm_prefork
pasará la solicitud al proceso hijo, y cada proceso hijo solo puede manejar una solicitud a la vez. Si el número actual de solicitudes excede
el número de procesos secundarios creados previamente, el módulo mpm_prefork creará nuevos procesos secundarios para manejar las solicitudes adicionales.
Apache siempre intenta reservar una cierta cantidad de procesos secundarios libres o inactivos para las solicitudes entrantes. De esta manera, el cliente solicitante
no tiene que esperar a que se genere el proceso hijo después de recibir la solicitud.
Dado que cada solicitud en el módulo mpm_prefork tiene un proceso secundario, consume más recursos del sistema que otros módulos
. Sin embargo, la ventaja del módulo mpm_prefork es que cada uno de sus procesos secundarios puede manejar una única solicitud de forma independiente, por lo que si una de las solicitudes falla, no afectará a las demás.
mpm_prefork es más eficiente que Worker, pero ocupa más memoria que Worker y no es muy bueno para manejar escenarios de alta concurrencia.
Descripción de parámetros de rendimiento importantes de Apache en modo pre-fork
#prefork MPM
StartServers 5 #apache StartServers 5 #El número de procesos secundarios iniciados de forma predeterminada al inicio MinSpareServers 5 #El número mínimo de procesos secundarios inactivos MaxSpareServers 10 #El número máximo de procesos secundarios inactivos MaxRequestWorkers 250 # MaxRequestWorkers establece el Número máximo de solicitudes entrantes simultáneas permitidas. Cualquier solicitud que exceda el límite de MaxRequestWorkers se colocará en una cola de espera. En versiones anteriores a Apache 2.3.1, MaxRequestWorkers se llamaba MaxClients. El nombre anterior todavía se admite. MaxConnectionsPerChild 500 #Establezca el número de solicitudes que cada proceso hijo puede manejar. Cada proceso secundario se destruirá automáticamente después de procesar "MaxConnectionsPerChild" 500 solicitudes. 0 significa infinito, es decir, el proceso hijo nunca será destruido. Si bien el valor predeterminado de 0 permite que cada proceso secundario maneje más solicitudes, establecerlo en un valor distinto de cero tiene dos beneficios importantes: 1) Previene pérdidas de memoria inesperadas. 2) Cuando la carga del servidor disminuye, automáticamente reducirá la cantidad de nodos secundarios. Por lo tanto, este valor se puede ajustar dependiendo de la carga del servidor . Antes de Apache 2.3.9, este valor se llamaba MaxRequestsPerChild.
Nota 1: MaxRequestWorkers es la más importante de estas directivas, establece el número de solicitudes que Apache puede manejar simultáneamente
. Es el parámetro que tiene mayor impacto en el rendimiento de Apache. Si el número total de solicitudes alcanza este valor (verificable con ps -ef|grep
http|wc -l), las solicitudes posteriores se pondrán en cola hasta que se procese una solicitud. Esta es la razón principal por la que el acceso HTTP es lento
cuando los recursos del sistema son suficientes. En teoría, cuanto mayor sea el valor, más solicitudes podrá manejar
, pero le recomendamos que establezca el valor inicial en (memoria física máxima en Mb/2) y luego ajuste dinámicamente según la carga.
Por ejemplo, para una máquina con memoria 4G, el valor inicial es 4000/2=2000.
Nota 2: Después de configurar inicialmente el proceso secundario "StartServers" para cumplir con los requisitos de la configuración de MinSpareServers, prebifurque el proceso de control
.p>
para crear un proceso, Espere un segundo, continúe creando dos procesos, espere otro segundo, continúe creando cuatro..., como
De esta manera, el número de procesos creados aumenta exponencialmente, y el número máximo de procesos creados por segundo es hasta 32, hasta que se detenga el valor de configuración de MinSpareServers
. En este modo, no es necesario iniciar un nuevo proceso cuando se recibe una solicitud, lo que reduce la sobrecarga del sistema y mejora el rendimiento.
MaxSpareServers establece el número máximo de procesos inactivos. Si el número de procesos inactivos es mayor que este valor, Apache eliminará automáticamente
algunos procesos redundantes. No establezca este valor demasiado alto, pero si establece un valor menor que MinSpareServers, Apache
lo ajustará automáticamente a MinSpareServers+1.
Nota 3 p>
Nota 3: ¿Cuál es la diferencia entre ServerLimit y MaxClients (MaxRequestWorkers)?
Esto se debe a que en la era apache1, el único parámetro que controlaba el número máximo de procesos era MaxClients, y el valor máximo de este parámetro era
256, y era difícil- codificado Debido al hardware del servidor en el límite de la era apache1, intentar establecerlo más allá de 256 no tiene ningún efecto
. Sin embargo, en la era Apache2, debido a las actualizaciones del hardware del servidor, el hardware ya no es un factor limitante, por lo que el parámetro
ServerLimit se usa para controlar el número máximo de procesos, y el valor de ServerLimit es solo > =MaxClient.ServerLimit
solo es válido. ServerLimit
se coloca antes de MaxClients y su valor no es menor que MaxClients. > o
[root@www ~]# apachectl -l (la L minúscula solo muestra módulos estáticos)
¿Cómo verificar el modo de trabajo de Apache? Puede usar el comando httpd -V para ver, o puede usar httpd -l para ver
Ver
Nota 5: Cómo cambiar los parámetros prefork y habilitar el modo prefork
1 .[root@www ~]# vi /usr/local/http-2.4.23/conf/ extra/httpd-mpm.conf
2.[root@www ~] # vi /usr/local /http-2.4.23/conf/httpd.conf
LoadModule mpm_prefork_module module/mod_prefork_module.so_mod_prefork_module mpm_prefork.so
Contiene conf/extra/httpd-mpm .conf
3 Reiniciar httpd
Modo de trabajo (multiproceso, multiproceso):
A diferencia del modo prefork, que utiliza una mezcla de multiproceso y subprocesos múltiples, el modo de trabajo también utiliza una combinación de subprocesos múltiples y subprocesos múltiples. A diferencia del modo prefork, el modo trabajador utiliza una combinación de multiprocesamiento y subprocesos múltiples. El modo de trabajo también preestablece
múltiples subprocesos. Cada subproceso crea múltiples subprocesos, incluido un subproceso de escucha, y cada solicitud entrante
.