Otimize o apache para 10K + visualizações de wordpress por dia em 2GB de RAM E6500 CPU

10

Eu tenho um servidor dedicado com apache / php no ubuntu que serve meu blog Wordpress com cerca de 10K + pageviews por dia. Eu tenho o plug-in do W3TC instalado com o APC.

Mas, de vez em quando, o servidor pára de responder ou fica inativo e eu preciso 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/
    
por Broke artist 07.01.2011 / 06:45

5 respostas

22

Meu desempenho do WordPress e a pilha de cache

Esta é uma grande pilha de desempenho do WordPress para um servidor único ou VPS de gama baixa a média. Eu estou classificando mid range como single core com cerca de 1G de memória e drives razoavelmente rápidos.

Na sua caixa, isso seria capaz de atender a mais de 10 mil page views por hora

Pilha de servidores

  • Linux - Debian Lenny ou Ubuntu
  • Nginx - Configurado como cache de arquivo estático do proxy reverso
  • Apache - O Apache manipulará o PHP transferido pelo Nginx em uma porta alternativa
  • MySql - Requerido pelo WP, verifique se você está executando a última versão estável
  • PHP - Última versão estável do ramo 5.2 ou 5.3

Cache do PHP

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

Pilha de plug-ins de desempenho do WordPress

  • Integrador de cache do proxy Nginx
  • W3 Total Cache - Defina o cache de páginas para disco aprimorado, diminua para disco e opte por db para APC .
  • CDN auto-hospedado - Crie 4 aliases de cname que apontam para o domínio no servidor configurado apenas para exibir arquivos estáticos

Com o W3 Total Cache, estamos usando o disco para o cache de páginas e diminuímos porque o Nginx estará atendendo nossos arquivos estáticos com muita rapidez.

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

O problema em 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 houver muito tráfego, suas conexões ficarão atoladas, mesmo que não estejam sendo usadas.

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

Configuração do Apache

link

defina KeepAlive como off

ports.conf

NameVirtualHost *:8080
Listen 8080

Por host virtual do site

<VirtualHost 127.0.0.1:8080>
     ServerAdmin [email protected]
     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 registros contenham os endereços IP reais de seus visitantes. Se não, seus registros terão 127.0.0.1 como o endereço IP de origem.

Configuração Nginx

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

$ 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 os 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 da fonte.

Nginx conf e configuração dos arquivos do servidor

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 habilitado para sites com cada v sym host ligado 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 só funcionarão se o plug-in do integrador de cache do 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 conf do site WordPress (Para o multi site você só precisa 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 seu CDN hospedado sozinho você só precisa configurá-lo para servir arquivos estáticos sem o passe 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, esta configuração pode, teoricamente, atender a 1833,56 solicitações por segundo

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

    
por 08.01.2011 / 18:51
0

Parece uma configuração padrão do Apache, embora pareça que parte dela tenha sido removida devido a sua aparência de HTML.

Você precisa investigar o que está acontecendo quando seu servidor responde lentamente. Você não diz as especificações do seu servidor, mas você menciona o seu dedicado e 10k / dia deve ser facilmente manipulado.

  • O que o top mostra?
  • Onde está o gargalo? CPU, memória, espera de E / S?
  • Quantos processos do Apache estão sendo executados?
  • Quantas conexões são mostradas no netstat?

Supondo que a CPU é provavelmente o gargalo causado pelo PHP. Usando APC e um plugin de cache 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". Certifique-se de ter memória suficiente alocada para o APC para que ele possa armazenar em cache seus scripts PHP e não "perder".

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

Considere desligar 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 'siege' ou 'ab' para avaliar seu servidor e descobrir em que ponto seu servidor fica mais lento.

Veja alguns dos meus favoritos do ajuste de desempenho do servidor: link

link

link

link

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

    
por 07.01.2011 / 07:03
0

Ative também o módulo 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 um (assumindo que a caixa não está fazendo mais nada). Seus MaxClients podem estar muito altos. A solução para isso é óbvia: adicione mais RAM ou menos MaxClients. Se a linha de comando demorar para responder quando você reiniciar o apache, isso é 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 assim todos os seus slots apache disponíveis. Talvez você tenha muito poucos MaxClients. Verificar o 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 livre é perlbal). velocidade quando você reinicia o apache, essa é uma indicação dessa situação.

    
por 07.01.2011 / 08:25
0

Usar mod_status é a maneira de ver o que está acontecendo dentro das várias instâncias do Apache, mas por favor, note que isso realmente prejudicará o desempenho. Parece comer memória e em um caso eu não era 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. Estes, claro, são relatados pelos usuários como "leva uma eternidade para carregar a página". Eles nem sequer entendem a diferença entre "seriam mais 10 segundos para esperar" e "isso nunca terminará", já que eles costumam pressionar Stop no navegador depois de alguns (< 10) segundos.

Verifique também se você está configurando o local correto (fácil de ver usando mod_status, já que você vê a quantidade de instâncias / processos). A configuração de estoque, pelo menos, no Ubuntu tem seções ifdefed por modo MPM e é fácil de editar o modo de trabalho quando você está executando o prefork (como sugerido pela sabedoria convencional fora de uma sensação difusa de que o PHP não é threadsafe).

Ah, e acima de tudo: corra em cima como root e veja os recursos maximizados. Memória, disco, CPU - você vai 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 do Comprimento do Conteúdo, fazendo com que o navegador espere por dados "para sempre", informando "dead slow" para "not respondendo ".

BTW: 10 mil páginas entregues por dia, além de arquivos de mídia nesta máquina, só devem ser um problema se todos visitarem em uma hora.

    
por 07.01.2011 / 10:14
0

Alguns conselhos, especialmente se você hospeda 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 a configuração do seu apache nos cabeçalhos. Verifique se as imagens e amp; outras mídias "estáveis" têm um tempo de expiração definido para uma data distante & que o seu apache retorna um código HTTP 304 quando solicitado pelos clientes
  • Ativar mod_deflate. Pode reduzir o desempenho de clientes que serão atendidos mais rapidamente.
por 07.01.2011 / 11:32