Otimize o apache para obter mais de 10 mil visualizações wordpress por dia na CPU E6500 de 2 GB de RAM


10

Eu tenho um servidor dedicado com apache / php no ubuntu, que serve no meu blog Wordpress com cerca de 10 mil visualizações de página por dia. Eu tenho o plug-in W3TC instalado com a APC.

Mas de vez em quando o servidor para de responder ou fica lento e eu tenho que reiniciar o apache para recuperá-lo.

Heres minha configuração o que estou fazendo de errado?

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/

Respostas:


23

Minha pilha de desempenho e cache do WordPress

Esta é uma excelente pilha de desempenho do WordPress para um servidor único ou VPS de faixa baixa a média. Estou classificando a faixa intermediária como núcleo único, com cerca de 1G de memória e unidades razoavelmente rápidas.

Na sua caixa, isso seria capaz de exibir mais de 10 mil visualizações de página por hora

Pilha de servidor

  • Linux - Debian Lenny ou Ubuntu
  • Nginx - configurado como cache de arquivo estático de proxy reverso
  • Apache - O Apache manipulará o PHP descarregado pelo Nginx em uma porta alternativa
  • MySql - Requerido pelo WP, verifique se você está executando a versão estável mais recente
  • Versão estável mais recente da ramificação 5.2 ou 5.3

Cache PHP

  • APC - Configure com memória mmap e tamanho shm de pelo menos 128M

Pilha de plug-ins de desempenho do WordPress

  • Integrador de cache proxy Nginx
  • W3 Total Cache - Defina o cache da página para o disco aprimorado, reduza para o disco e o objeto e db para APC.
  • CDN auto-hospedado - Crie 4 aliases de cname que apontam para o domínio no servidor configurado apenas para servir arquivos estáticos

Com o W3 Total Cache, estamos usando o disco para o cache da página e o minify, pois o Nginx servirá nossos arquivos estáticos muito rapidamente.

Como configurar o Nginx para servir arquivos estáticos e passar o PHP ao Apache

O problema de usar o Apache sozinho é que ele abre uma conexão e atinge o php em todas as solicitações, mesmo para arquivos estáticos. Isso desperdiça conexões porque o Apache as manterá abertas e quando você tiver muito tráfego, suas conexões serão bloqueadas, mesmo que não estejam sendo usadas.

Por padrão, o Apache escuta solicitações na porta 80, que é a porta da web padrão. Primeiro, faremos alterações nos arquivos conf e Apache hosts do Apache para escutar na porta 8080.

Configuração do Apache

httpd.conf

defina KeepAlive como desativado

ports.conf

NameVirtualHost *:8080
Listen 8080

Host virtual por site

<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>

Você também deve instalar o mod_rpaf para que seus logs contenham os endereços IP reais de seus visitantes. Caso contrário, seus logs terão 127.0.0.1 como o endereço IP de origem.

Nginx Config

No Debian você pode usar os repositórios para instalar, mas eles contêm apenas a versão 0.6.33. Para instalar uma versão posterior, você deve adicionar os pacotes lenny backports

$ nano /etc/apt/sources.list

Adicione esta linha ao arquivo deb http://www.backports.org/debian lenny-backports main

$ nano /etc/apt/preferences

Adicione o seguinte ao arquivo:

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

Emita os seguintes comandos para importar a chave do backports.org para verificar pacotes e atualizar o banco de dados de pacotes do seu sistema:

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

Agora instale com o apt-get

apt-get install nginx

Isso é muito mais fácil do que compilar a partir do código-fonte.

Configuração dos arquivos conf e servidor Nginx

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/*;
}

Agora você precisará configurar sua hospedagem virtual Nginx. Eu gosto de usar o método ativado por sites com cada sy do host v vinculado a um arquivo no diretório de sites disponíveis.

$ 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:

As configurações de cache estático nos arquivos a seguir funcionarão apenas se o plug-in integrador de cache proxy Nginx estiver ativado.

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;
}

Por conf do site WordPress (Para sites múltiplos, você precisará apenas de um 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 auto-hospedado

Para sua conf CDN auto-hospedada, você só precisa configurá-la para servir arquivos estáticos sem a passagem 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;
        }

    }

Agora inicie os servidores

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

Os Resultados de Referência

No Apache Bench, essa configuração pode atender teoricamente 1833,56 solicitações por segundo

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

texto alternativo


Você mencionou que o nginx lida com arquivos estáticos e o apache lida com arquivos php, mas no bloco de arquivos estáticos você tem "proxy_pass wordpressapache ;". Isso não significa que o apache está manipulando os arquivos estáticos?
srchulo

0

Parece uma configuração padrão do Apache, embora pareça que algumas delas foram removidas devido à aparência de HTML.

Você precisa investigar o que está acontecendo quando o servidor responde lentamente. Você não diz as especificações do seu servidor, mas menciona que elas são dedicadas e 10k / dia devem ser manipuladas com facilidade.

  • O que mostra top?
  • Onde está o gargalo? CPU, memória, E / S Espera?
  • Quantos processos Apache estão em execução?
  • Quantas conexões mostradas no netstat?

Acho que a CPU é provavelmente o gargalo causado pelo PHP. O uso da APC e um plug-in de cache do WP são bons métodos para aliviar isso, o que você já fez. Você também pode tentar o modelo de processo "MPM" do Apache em vez de "Prefork". Verifique se você possui memória suficiente alocada para a APC, para que ela possa armazenar em cache seus scripts PHP e não "errar".

Também pode ser o MySQL - veja se isso está sobrecarregando a CPU ou o disco.

Considere desativar o mod_deflate se você o tiver ativado - ele fornece benefícios aos tempos de carregamento, mas pode aumentar a carga da CPU. Pode valer a pena tentar.

Use uma ferramenta como 'cerco' ou 'ab' para comparar seu servidor e descobrir em que ponto o servidor diminui.

Aqui estão alguns dos meus favoritos do ajuste de desempenho do servidor da 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/

Mas meu conselho original permanece o mesmo - descubra qual é o primeiro gargalo! Caso contrário, você está tentando cegamente melhorar o desempenho (e com certeza, melhorar o desempenho é sempre bom), mas sem saber em qual área focar sua atenção.


0

Ative também o módulo de status do servidor e visite-o para descobrir o que está acontecendo.

Você pode estar trocando. Você verificou o vmstat enquanto isso está acontecendo? 2 GB de RAM para 80 MaxClients é de apenas 25 MB para cada (assumindo que a caixa não esteja fazendo mais nada.) Seus MaxClients podem estar muito altos. A solução para isso é óbvia: adicione mais RAM ou reduza o MaxClients. Se a linha de comando demorar a responder quando você reiniciar o apache, essa é uma indicação dessa situação.

Também é possível que você esteja alimentando alguns clientes móveis (ou outros clientes em conexões lentas) com arquivos 'grandes', consumindo todos os slots apache disponíveis. Talvez você tenha muito poucos MaxClients. A verificação do status do servidor informará o que cada um desses clientes está fazendo naquele momento. Uma solução para essa situação é aumentar o MaxClients (mas isso também pode se transformar na situação acima.) Uma solução melhor para isso é instalar um acelerador HTTP na frente do apache (uma opção gratuita é perlbal.) Se sua linha de comando estiver normal velocidade ao reiniciar o apache, essa é uma indicação dessa situação.


0

Usar mod_status é a maneira de ver o que está acontecendo dentro das várias instâncias do Apache, mas observe que isso realmente prejudicará o desempenho. Parece consumir memória e, em um caso, não fui capaz de diagnosticar se era a causa de bloqueios de processo único em uma configuração somente de proxy reverso, onde nada era servido diretamente. Obviamente, eles são relatados pelos usuários como "leva uma eternidade para carregar a página". Eles nem entendem a diferença entre "levaria mais 10 segundos para esperar" e "isso nunca terminará", pois eles geralmente pressionam Stop no navegador após alguns (<10) segundos.

Verifique também se você está configurando o local correto (fácil de ver usando mod_status, pois você vê a quantidade de instâncias / processos). A configuração de ações, pelo menos no ubuntu, possui seções definidas por modo MPM e é fácil editar o modo de trabalho quando você estiver executando o prefork (como sugerido pela sabedoria convencional, por um sentimento difuso de que o PHP não é seguro para threads).

Ah, e acima de tudo: Run no topo como root e relógio para ressources maxed para fora. Memória, disco, CPU - você verá.

Mais uma: A idéia de desativar o mod_deflate pode ser boa, embora sua configuração não seja propensa ao erro de informações incorretas sobre o comprimento do conteúdo, fazendo com que o navegador aguarde os dados "para sempre", fornecendo relatórios de "devagar" para "não responder".

BTW: 10.000 páginas entregues por dia mais arquivos de mídia nesta máquina só devem ser um problema se todos vierem visitar em uma hora.


0

Alguns conselhos, especialmente se você hospedar muitos arquivos de mídia:

  • Mova suas mídias para uma instância dedicada do Apache (ou melhor: nginx). Sem PHP, sem módulos, apenas um servidor HTTP simples que fornecerá mídias o mais rápido possível.
  • Cache, cache, cache! Use o plugin super cache no wordpress. Isso ajuda muito.
  • Verifique sua configuração do apache nos cabeçalhos. Verifique se as imagens e outras mídias "estáveis" têm um tempo de expiração definido para uma data distante e se o seu apache retorna um código HTTP 304 quando solicitado pelos clientes
  • Ative mod_deflate. Isso pode reduzir o desempenho dos clientes, que serão atendidos mais rapidamente.
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.