Optimice apache para vistas de 10K + wordpress al día en CPU de 2GB RAM E6500


10

Tengo un servidor dedicado con apache / php en ubuntu que sirve mi blog de Wordpress con aproximadamente 10K + páginas vistas al día. Tengo el complemento W3TC instalado con APC.

Pero de vez en cuando el servidor deja de responder o se apaga lentamente y tengo que reiniciar Apache para recuperarlo.

Aquí está mi configuración, ¿qué estoy haciendo mal?

ServerRoot "/etc/apache2"
LockFile /var/lock/apache2/accept.lock
PidFile ${APACHE_PID_FILE}
TimeOut 40
KeepAlive on
MaxKeepAliveRequests 200
KeepAliveTimeout 2
<IfModule mpm_prefork_module>
  StartServers 5
  MinSpareServers 5
  MaxSpareServers 8
  ServerLimit        80
  MaxClients         80
  MaxRequestsPerChild 1000
</IfModule>
<IfModule mpm_worker_module>
  StartServers       3
  MinSpareServers    3
  MaxSpareServers    3
  ServerLimit        80
  MaxClients         80
  MaxRequestsPerChild  1000
</IfModule>
<IfModule mpm_event_module>
  StartServers       3
  MinSpareServers    3
  MaxSpareServers    3
  ServerLimit        80
  MaxClients         80
  MaxRequestsPerChild  1000
</IfModule>
User ${APACHE_RUN_USER}
Group ${APACHE_RUN_GROUP}
AccessFileName .htaccess
<Files ~ "^\.ht">
  Order allow,deny
  Deny from all
  Satisfy all
</Files>
DefaultType text/plain
HostnameLookups Off
ErrorLog /var/log/apache2/error.log
LogLevel error
Include /etc/apache2/mods-enabled/*.load
Include /etc/apache2/mods-enabled/*.conf
Include /etc/apache2/httpd.conf
Include /etc/apache2/ports.conf
LogFormat "%v:%p %h %l %u %t \"%r\" %>s %O \"%{Referer}i\" \"%{User-Agent}i\"" vhost_combined
LogFormat "%h %l %u %t \"%r\" %>s %O \"%{Referer}i\" \"%{User-Agent}i\"" combined
LogFormat "%h %l %u %t \"%r\" %>s %O" common
LogFormat "%{Referer}i -> %U" referer
LogFormat "%{User-agent}i" agent
CustomLog /var/log/apache2/other_vhosts_access.log vhost_combined
Include /etc/apache2/conf.d/
Include /etc/apache2/sites-enabled/

Respuestas:


23

Mi rendimiento de WordPress y la pila de almacenamiento en caché

Esta es una gran pila de rendimiento de WordPress para un servidor único o VPS de rango bajo a medio. Estoy clasificando el rango medio como núcleo único con alrededor de 1G de memoria y unidades bastante rápidas.

En su caja, esto sería capaz de servir más de 10 mil visitas a la página por hora.

Pila del servidor

  • Linux: Debian Lenny o Ubuntu
  • Nginx: configurado como caché de archivos estáticos de proxy inverso
  • Apache: Apache manejará el PHP descargado por Nginx en un puerto alternativo
  • MySql: requerido por WP, asegúrese de ejecutar la última versión estable
  • PHP: última versión estable de la rama 5.2 o 5.3

Caché PHP

  • APC: configúrelo con memoria mmap y tamaño shm de al menos 128M

Pila de plugins de rendimiento de WordPress

  • Integrador de caché proxy Nginx
  • W3 Total Cache : establece la memoria caché de la página en el disco mejorado, minimiza en el disco y objeta y db en APC.
  • CDN autohospedado: cree 4 alias de cname que apuntan al dominio en el servidor configurado solo para servir archivos estáticos

Con W3 Total Cache estamos usando el disco para el caché de páginas y minify porque Nginx servirá nuestros archivos estáticos muy rápido.

Cómo configurar Nginx para servir archivos estáticos y pasar PHP a Apache

El problema con el uso de Apache solo es que abre una conexión y golpea php en cada solicitud, incluso para archivos estáticos. Esto desperdicia conexiones porque Apache las mantendrá abiertas y cuando tenga mucho tráfico sus conexiones se empantanarán incluso si no se están utilizando.

De forma predeterminada, Apache escucha las solicitudes en el puerto 80, que es el puerto web predeterminado. Primero vamos a hacer cambios en nuestros archivos Apache conf y hosts virtuales para escuchar en el puerto 8080.

Configuración de Apache

httpd.conf

establecer KeepAlive en apagado

ports.conf

NameVirtualHost *:8080
Listen 8080

Por host virtual de sitio

<VirtualHost 127.0.0.1:8080>
     ServerAdmin info@yoursite.com
     ServerName yoursite.com
     ServerAlias www.yoursite.com
     DocumentRoot /srv/www/yoursite.com/public_html/
     ErrorLog /srv/www/yoursite.com/logs/error.log
     CustomLog /srv/www/yoursite.com/logs/access.log combined
</VirtualHost>

También debe instalar mod_rpaf para que sus registros contengan las direcciones IP reales de sus visitantes. Si no, sus registros tendrán 127.0.0.1 como la dirección IP de origen.

Nginx Config

En Debian puede usar los repositorios para instalar, pero solo contienen la versión 0.6.33. Para instalar una versión posterior, debe agregar los paquetes de lenny backports

$ nano /etc/apt/sources.list

Agregue esta línea al archivo deb http://www.backports.org/debian lenny-backports main

$ nano /etc/apt/preferences

Agregue lo siguiente al archivo:

Package: nginx
Pin: release a=lenny-backports 
Pin-Priority: 999

Emita los siguientes comandos para importar la clave de backports.org para verificar paquetes y actualizar la base de datos de paquetes de su sistema:

$ wget -O - http://backports.org/debian/archive.key | apt-key add -
$ apt-get update

Ahora instale con apt-get

apt-get install nginx

Esto es mucho más fácil que compilar desde la fuente.

Configuración de Nginx conf y server files

nginx.conf

user www-data;
worker_processes  4;

error_log  /var/log/nginx/error.log;
pid        /var/run/nginx.pid;

events {
    worker_connections  1024;
}

http {
    include       /etc/nginx/mime.types;
    default_type  application/octet-stream;

    access_log  /var/log/nginx/access.log;
    client_body_temp_path /var/lib/nginx/body 1 2;
    gzip_buffers 32 8k;
    sendfile        on;
    #tcp_nopush     on;

    #keepalive_timeout  0;
    keepalive_timeout  65;
    tcp_nodelay        on;

    gzip  on;

  gzip_comp_level   6;
  gzip_http_version 1.0;
  gzip_min_length   0;
  gzip_types        text/html text/css image/x-icon
        application/x-javascript application/javascript text/javascript application/atom+xml application/xml ;



    include /etc/nginx/conf.d/*.conf;
    include /etc/nginx/sites-enabled/*;
}

Ahora deberá configurar su alojamiento virtual Nginx. Me gusta usar el método habilitado para sitios con cada símbolo de host v vinculado a un archivo en el directorio de sitios disponibles.

$ mkdir /etc/nginx/sites-available  
$ mkdir /etc/nginx/sites-enabled
$ touch /etc/nginx/sites-available/yourservername.conf
$ touch /etc/nginx/sites-available/default.conf
$ ln -s  /etc/nginx/sites-available /etc/nginx/sites-enabled
$ nano /etc/nginx/sites-enabled/default.conf

default.conf

Nota:

La configuración de caché estática en los siguientes archivos solo funcionará si el complemento integrador de caché proxy Nginx está habilitado.

proxy_cache_path  /var/lib/nginx/cache  levels=1:2   keys_zone=staticfilecache:180m  max_size=500m;
proxy_temp_path /var/lib/nginx/proxy;
proxy_connect_timeout 30;
proxy_read_timeout 120;
proxy_send_timeout 120;

#IMPORTANT - this sets the basic cache key that's used in the static file cache.
proxy_cache_key "$scheme://$host$request_uri";

upstream wordpressapache {
        #The upstream apache server. You can have many of these and weight them accordingly,
        #allowing nginx to function as a caching load balancer 
        server 127.0.0.1:8080 weight=1 fail_timeout=120s;
}

Según la configuración del sitio de WordPress (para sitios múltiples solo necesitará un vhost)

server {
        #Only cache 200 responses, and for a default of 20 minutes.
        proxy_cache_valid 200 20m;

        #Listen to your public IP
        listen 80;

        #Probably not needed, as the proxy will pass back the host in "proxy_set_header"
        server_name www.yoursite.com yoursite.com;
        access_log /var/log/nginx/yoursite.proxied.log;  

        # "combined" matches apache's concept of "combined". Neat.
        access_log  /var/log/apache2/nginx-access.log combined;
        # Set the real IP.
        proxy_set_header X-Real-IP  $remote_addr;

        # Set the hostname
        proxy_set_header Host $host;

        #Set the forwarded-for header.
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

        location / {
                        # If logged in, don't cache.
                        if ($http_cookie ~* "comment_author_|wordpress_(?!test_cookie)|wp-postpass_" ) {
                                set $do_not_cache 1;
                        }
                        proxy_cache_key "$scheme://$host$request_uri $do_not_cache";
                        proxy_cache staticfilecache;
                        proxy_pass http://wordpressapache;
        }

        location ~* wp\-.*\.php|wp\-admin {
                        # Don't static file cache admin-looking things.
                        proxy_pass http://wordpressapache;
        }

        location ~* \.(jpg|png|gif|jpeg|css|js|mp3|wav|swf|mov|doc|pdf|xls|ppt|docx|pptx|xlsx)$ {
                        # Cache static-looking files for 120 minutes, setting a 10 day expiry time in the HTTP header,
                        # whether logged in or not (may be too heavy-handed).
                        proxy_cache_valid 200 120m;
                        expires 864000;
                        proxy_pass http://wordpressapache;
                        proxy_cache staticfilecache;
        }

        location ~* \/[^\/]+\/(feed|\.xml)\/? {
 # Cache RSS looking feeds for 45 minutes unless logged in.
                        if ($http_cookie ~* "comment_author_|wordpress_(?!test_cookie)|wp-postpass_" ) {
                                set $do_not_cache 1;
                        }
                        proxy_cache_key "$scheme://$host$request_uri $do_not_cache";
                        proxy_cache_valid 200 45m;
                        proxy_cache staticfilecache;
                        proxy_pass http://wordpressapache;
        }

        location = /50x.html {
                root   /var/www/nginx-default;
        }

        # No access to .htaccess files.
        location ~ /\.ht {
                deny  all;
        }

        }

Conf. CDN autohospedado

Para su conf CDN autohospedado solo necesita configurarlo para servir archivos estáticos sin el pase de proxy

server {

        proxy_cache_valid 200 20m;
        listen 80;
        server_name yourcdndomain.com;
        access_log   /srv/www/yourcdndomain.com/logs/access.log;
        root   /srv/www/yourcdndomain.com/public_html/;

 proxy_set_header X-Real-IP  $remote_addr;

      location ~* \.(jpg|png|gif|jpeg|css|js|mp3|wav|swf|mov|doc|pdf|xls|ppt|docx|pptx|xlsx)$ {
                                # Cache static-looking files for 120 minutes, setting a 10 day expiry time in the HTTP header,
                                # whether logged in or not (may be too heavy-handed).

                                proxy_cache_valid 200 120m;
                        expires 7776000;
                        proxy_cache staticfilecache;
                }

location = /50x.html {
                root   /var/www/nginx-default;
        }

 # No access to .htaccess files.
        location ~ /\.ht {
          deny  all;
        }

    }

Ahora inicia los servidores

$ /etc/init.d/apache2 restart  
$/etc/init.d/nginx start

Los resultados de referencia

En Apache Bench, esta configuración teóricamente puede atender 1833.56 solicitudes por segundo

$ ab -n 1000 -c 20 http://yoursite.com/

texto alternativo


Usted menciona que nginx maneja archivos estáticos y apache maneja archivos php, pero en el bloque de archivos estáticos tiene "proxy_pass wordpressapache ;". ¿No significa eso que Apache está manejando los archivos estáticos?
srchulo

0

Parece una configuración estándar de Apache, aunque parece que parte de ella se ha eliminado debido a que parece HTML.

Debe investigar qué sucede cuando su servidor responde lentamente. No dice las especificaciones de su servidor, pero menciona que es dedicado y que 10k / día deben manejarse fácilmente.

  • ¿Qué muestra top?
  • ¿Dónde está el cuello de botella? CPU, memoria, E / S ¿Esperar?
  • ¿Cuántos procesos de Apache se están ejecutando?
  • ¿Cuántas conexiones se muestran en netstat?

Adivinando, la CPU es probablemente el cuello de botella causado por PHP. El uso de APC y un complemento de almacenamiento en caché de WP son buenos métodos para aliviar esto, lo cual ya ha hecho. También puede probar el modelo de proceso "MPM" de Apache en lugar de "Prefork". Asegúrese de tener suficiente memoria asignada a APC para que pueda almacenar en caché sus scripts PHP y no 'fallar'.

También podría ser MySQL; vea si eso está acaparando la CPU o el disco.

Considere desactivar mod_deflate si lo tiene habilitado; proporciona beneficios a los tiempos de carga, pero puede aumentar la carga de la CPU. Puede valer la pena intentarlo.

Use una herramienta como 'asedio' o 'ab' para comparar su servidor y determinar en qué punto su servidor se ralentiza.

Estos son algunos de mis marcadores del ajuste del rendimiento del servidor web: http://articles.slicehost.com/2010/5/19/configuring-the-apache-mpm-on-ubuntu

http://www.thebuzzmedia.com/increase-wordpress-performance-on-apache-with-worker-mpm-php-and-mod_fcgid/

http://www.devside.net/articles/apache-performance-tuning

http://www.brandonturner.net/blog/2009/07/fastcgi_with_php_opcode_cache/

Pero mi consejo original sigue siendo el mismo: ¡descubra cuál es el cuello de botella primero! De lo contrario, intenta ciegamente mejorar el rendimiento (y seguro, mejorar el rendimiento siempre es bueno) pero sin saber en qué área enfocar su atención.


0

También habilite el módulo de estado del servidor y visítelo para averiguar qué está sucediendo.

Podrías estar intercambiando. ¿Has echado un vistazo a vmstat mientras esto sucede? 2 GB de RAM para 80 MaxClients son solo 25 MB para cada uno (suponiendo que la caja no esté haciendo nada más). Sus MaxClients pueden ser demasiado altos. La solución para esto es obvia: agregue más RAM o MaxClients más bajos. Si la línea de comando tarda en responder cuando reinicia Apache, esa es una indicación de esta situación.

También es posible que esté alimentando con cuchara a algunos clientes móviles (u otros clientes en conexiones lentas) con archivos 'grandes', consumiendo así todas sus ranuras de apache disponibles. Tal vez tienes muy pocos MaxClients. Verificando el estado del servidor le dirá qué está haciendo cada uno de esos clientes en ese momento. Una solución para esta situación es aumentar los MaxClients (pero eso también podría convertirse en la situación anterior). Una mejor solución para esto es instalar un acelerador HTTP frente a apache (una opción gratuita es perlbal). Si su línea de comando es normal velocidad cuando reinicia Apache, esa es una indicación de esta situación.


0

El uso de mod_status es la forma de ver lo que sucede dentro de las múltiples instancias de Apache, pero tenga en cuenta que realmente afectará el rendimiento. Parece comer memoria y, en un caso, no pude diagnosticar si fue la causa de bloqueos de un solo proceso en un entorno de proxy inverso solo donde nada se sirvió directamente. Por supuesto, estos son reportados por los usuarios como "se tarda una eternidad en cargar la página". Ni siquiera entienden la diferencia entre "hubieran sido 10 segundos más de espera" y "nunca terminará", ya que generalmente presionan Stop en su navegador después de algunos (<10) segundos.

También verifique si está configurando el lugar correcto (fácil de ver usando mod_status ya que ve la cantidad de instancias / procesos). La configuración estándar al menos en ubuntu tiene secciones ifdef'ed por modo MPM y es fácil editar el modo trabajador cuando está ejecutando prefork (como lo sugiere la sabiduría convencional por la sensación difusa de que PHP no es seguro para subprocesos).

Ah, y sobre todo: Ejecutar la cima como root y reloj de Recursos llegado al máximo. Memoria, disco, CPU: ya lo verá.

Una más: la idea de desactivar mod_deflate puede ser buena, aunque su configuración no es propensa al error de información incorrecta sobre la longitud del contenido, lo que hace que el navegador espere datos "para siempre" y le informe de "lentitud" para "no responder".

Por cierto: 10K páginas entregadas por día más archivos multimedia en esta máquina solo deberían ser un problema si todos visitan en una hora.


0

Algunos consejos, especialmente si aloja muchos archivos multimedia:

  • Mueva sus medios a una instancia dedicada de Apache (o mejor: nginx). Sin PHP, sin módulos, solo un servidor http simple que entregará medios lo más rápido posible.
  • Caché, caché, caché! Use el complemento súper caché en WordPress. Esto ayuda mucho.
  • Verifique su configuración de apache en los encabezados. Verifique que las imágenes y otros medios "estables" tengan un tiempo de caducidad establecido en una fecha distante y que su apache devuelva un código HTTP 304 cuando lo soliciten los clientes
  • Habilite mod_deflate. Puede reducir el rendimiento de los clientes será más rápido servido
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.