Ottimizza apache per 10K + visualizzazioni wordpress al giorno su CPU E6500 RAM da 2 GB


10

Ho un server dedicato con apache / php su Ubuntu che serve il mio blog Wordpress con circa 10K + visualizzazioni di pagina al giorno. Ho installato il plug W3TC con APC.

Ma ogni tanto il server smette di rispondere o si spegne lentamente e devo riavviare apache per riaverlo.

Ecco la mia configurazione cosa sto facendo di sbagliato?

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/

Risposte:


23

My WordPress Performance e Caching Stack

Questo è un ottimo stack di prestazioni di WordPress per un singolo server o VPS di fascia medio-bassa. Sto classificando la gamma media come single core con circa 1G di memoria e unità abbastanza veloci.

Sulla tua scatola questo sarebbe in grado di offrire oltre 10K visualizzazioni di pagina all'ora

Stack di server

  • Linux - Debian Lenny o Ubuntu
  • Nginx: configurato come cache di file statici proxy inverso
  • Apache: Apache gestirà il PHP scaricato da Nginx su una porta alternativa
  • MySql: richiesto da WP, assicurati di eseguire l'ultima versione stabile
  • PHP - Ultima versione stabile del ramo 5.2 o 5.3

Cache PHP

  • APC: configuralo con memoria mmap e dimensioni shm di almeno 128M

Stack di plugin per prestazioni WordPress

  • Integratore di cache proxy Nginx
  • W3 Total Cache - Imposta la cache della pagina su disco migliorato, minimizza su disco e oggetti e db su APC.
  • Self Hosted CDN - Crea 4 alias di cname che puntano al dominio sul server impostato solo per servire file statici

Con W3 Total Cache stiamo usando il disco per la cache della pagina e minimizziamo perché Nginx servirà i nostri file statici molto velocemente.

Come configurare Nginx per servire file statici e passare PHP ad Apache

Il problema con l'utilizzo di Apache da solo è che apre una connessione e colpisce php su ogni richiesta anche per i file statici. Questo spreca le connessioni perché Apache le terrà aperte e quando hai molto traffico le tue connessioni verranno bloccate anche se non vengono utilizzate.

Per impostazione predefinita, Apache è in attesa di richieste sulla porta 80, che è la porta Web predefinita. Per prima cosa faremo modifiche ai nostri file di configurazione e host virtuali di Apache per l'ascolto sulla porta 8080.

Config Apache

httpd.conf

disattivare KeepAlive

ports.conf

NameVirtualHost *:8080
Listen 8080

Host virtuale per sito

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

Dovresti anche installare mod_rpaf in modo che i tuoi log contengano gli indirizzi IP reali dei tuoi visitatori. In caso contrario, i tuoi registri avranno 127.0.0.1 come indirizzo IP di origine.

Config Nginx

Su Debian è possibile usare i repository per l'installazione ma contengono solo la versione 0.6.33. Per installare una versione successiva è necessario aggiungere i pacchetti di backport di lenny

$ nano /etc/apt/sources.list

Aggiungi questa riga al file deb http://www.backports.org/debian lenny-backports main

$ nano /etc/apt/preferences

Aggiungi quanto segue al file:

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

Immettere i comandi seguenti per importare la chiave da backports.org per verificare i pacchetti e aggiornare il database dei pacchetti del sistema:

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

Ora installa con apt-get

apt-get install nginx

Questo è molto più semplice della compilazione dal sorgente.

Config Nginx e configurazione dei file server

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

Ora dovrai configurare il tuo hosting virtuale Nginx. Mi piace usare il metodo abilitato per i siti con ogni sym v host collegato a un file nella directory dei siti disponibili.

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

Le impostazioni della cache statica nei seguenti file funzioneranno solo se il plug-in integratore della cache proxy Nginx è abilitato.

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

Per la configurazione del sito WordPress (per più siti è necessario un solo 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 self-hosted

Per la tua configurazione CDN self hosted devi solo configurarlo per servire file statici senza il proxy pass

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

    }

Ora avvia i server

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

I risultati del benchmark

Su Apache Bench questa configurazione può teoricamente servire 1833,56 richieste al secondo

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

testo alternativo


Hai detto che nginx gestisce i file statici e apache gestisce i file php, ma nel blocco dei file statici hai "proxy_pass wordpressapache ;". Ciò non significa che Apache sta gestendo i file statici?
srchulo,

0

Sembra una configurazione standard di Apache anche se sembra che alcuni di essi siano stati rimossi a causa dell'aspetto HTML.

Devi investigare cosa sta succedendo quando il tuo server risponde lentamente. Non dite le specifiche del vostro server ma menzionate il suo dedicato e 10k / day dovrebbero essere facilmente gestite.

  • Cosa mostra in alto?
  • Dov'è il collo di bottiglia? CPU, memoria, I / O Aspetta?
  • Quanti processi Apache sono in esecuzione?
  • Quante connessioni mostrate in netstat?

Indovina, la CPU è probabilmente il collo di bottiglia causato da PHP. L'uso di APC e un plug-in di memorizzazione nella cache WP sono buoni metodi per alleviare ciò, cosa che hai già fatto. Puoi anche provare il modello di processo "MPM" di Apache anziché "Prefork". Assicurati di avere abbastanza memoria allocata ad APC in modo che possa memorizzare nella cache gli script PHP e non "perdere".

Potrebbe anche essere MySQL - vedi se è il hogging della CPU o del disco.

Prendi in considerazione la disattivazione di mod_deflate se lo hai abilitato: fornisce vantaggi per i tempi di caricamento, ma può aumentare il carico della CPU. Vale la pena provare.

Usa uno strumento come 'assedio' o 'ab' per confrontare il tuo server e capire a che punto il tuo server rallenta.

Ecco alcuni dei miei segnalibri del tuning delle prestazioni del server 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/

Ma il mio consiglio originale rimane lo stesso: scopri qual è il primo collo di bottiglia! Altrimenti stai cercando ciecamente di migliorare le prestazioni (e sicuramente, migliorare le prestazioni è sempre buono) ma senza sapere quale area focalizzare la tua attenzione.


0

Abilita anche il modulo di stato del server e visita quello per scoprire cosa sta succedendo.

Potresti scambiare. Hai verificato vmstat mentre questo sta accadendo? 2 GB di RAM per 80 MaxClients sono solo 25 MB per ciascuno (supponendo che la scatola non stia facendo altro.) I tuoi MaxClients potrebbero essere troppo alti. La soluzione è ovvia: aggiungi più RAM o meno MaxClients. Se la riga di comando risponde lentamente al riavvio di apache, questa è un'indicazione di questa situazione.

È anche possibile che tu stia alimentando alcuni client mobili (o altri client su connessioni lente) con file "grandi" consumando così tutti gli slot Apache disponibili. Forse hai troppi MaxClients. Il controllo dello stato del server ti dirà cosa sta facendo ciascuno di quei client in quel momento. Una soluzione per questa situazione è aumentare MaxClients (ma ciò potrebbe anche trasformarsi nella situazione sopra.) Una soluzione migliore per questo è installare un acceleratore HTTP davanti ad apache (un'opzione gratuita è perlbal.) Se la tua riga di comando è normale velocità quando riavvii apache, questa è un'indicazione di questa situazione.


0

L'uso di mod_status è il modo di vedere cosa sta succedendo all'interno delle molteplici istanze di Apache, ma tieni presente che comprometterà davvero le prestazioni. Sembra consumare memoria e in un caso non sono stato in grado di diagnosticare se fosse la causa di blocchi di singoli processi in un'impostazione di solo proxy inverso in cui non veniva servito direttamente. Questi, naturalmente, sono riportati dagli utenti come "ci vuole un'eternità per caricare la pagina". Non capiscono nemmeno la differenza tra "ci sarebbero voluti altri 10 secondi per aspettare" e "non finirà mai" dato che di solito premono Stop nel loro browser dopo alcuni (<10) secondi.

Controlla anche se stai configurando il posto giusto (facile da vedere usando mod_status poiché vedi la quantità di istanze / processi). La configurazione di magazzino almeno in Ubuntu ha sezioni ifdef definite per modalità MPM ed è facile modificare la modalità lavoratore quando si esegue prefork (come suggerito dalla saggezza convenzionale da una sensazione sfocata che PHP non è sicuro).

Oh, e soprattutto: corri in cima come root e osserva le risorse al massimo. Memoria, disco, CPU: vedrai.

Ancora uno: L'idea di disattivare mod_deflate potrebbe essere buona, sebbene l'impostazione non sia soggetta all'errore di informazioni errate sulla lunghezza del contenuto che inducono il browser ad attendere i dati "per sempre", dandoti rapporti da "lento lento" a "non rispondente".

A proposito: 10K pagine consegnate al giorno più i file multimediali su questa macchina dovrebbero essere un problema solo se arrivano tutti in un'ora.


0

Alcuni consigli, soprattutto se si ospitano molti file multimediali:

  • Sposta i tuoi media in un'istanza dedicata di Apache (o meglio: nginx). Nessun PHP, nessun modulo, solo un server http nudo che fornirà i media il più velocemente possibile.
  • Cache, cache, cache! Usa il plugin super cache su wordpress. Aiuta molto.
  • Controlla la tua configurazione di apache sulle intestazioni. Verifica che le immagini e altri media "stabili" abbiano un tempo di scadenza impostato su una data lontana e che il tuo apache restituisca un codice HTTP 304 quando richiesto dai client
  • Abilita mod_deflate. Può ridurre le prestazioni da parte dei clienti che saranno servite più velocemente.
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.