10 votes

Optimisation d'apache pour 10K+ vues de wordpress par jour sur un CPU E6500 de 2GB RAM

J'ai un serveur dédié avec apache/php sur ubuntu qui sert mon blog Wordpress avec environ 10K+ pages vues par jour. J'ai installé le plug-in W3TC avec APC.

Mais de temps en temps, le serveur cesse de répondre ou devient très lent et je dois redémarrer Apache pour le rétablir.

Voici ma configuration, qu'est-ce que je fais de 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/

23voto

Myer Points 1892

Ma pile de performance et de mise en cache pour WordPress

Il s'agit d'une excellente pile de performance WordPress pour un serveur simple ou un VPS de bas à moyen de gamme. Je classifie le milieu de gamme comme un simple cœur avec environ 1G de mémoire et des disques assez rapides.

Avec votre système, vous seriez capable de servir plus de 10 000 pages vues par heure.

Pile de serveurs

  • Linux - soit Debian Lenny soit Ubuntu
  • Nginx - Configuré comme reverse proxy cache de fichiers statiques
  • Apache - Apache gérera le PHP déchargé par Nginx sur un autre port.
  • MySql - Requis par WP, assurez-vous que vous utilisez la dernière version stable.
  • PHP - Dernière version stable de la branche 5.2 ou 5.3

Cache PHP

  • APC - Configurez-le avec de la mémoire mmap et une taille de shm d'au moins 128M

Pile de plugins de performance WordPress

  • Intégrateur de cache proxy Nginx
  • W3 Total Cache - Définir le cache des pages sur le disque amélioré, le minage sur le disque, et l'objet et le db sur APC.
  • Self Hosted CDN - Créez 4 alias cname qui pointent vers le domaine sur le serveur mis en place uniquement pour servir les fichiers statiques.

Avec W3 Total Cache, nous utilisons le disque pour le cache des pages et le minage car Nginx servira nos fichiers statiques très rapidement.

Comment configurer Nginx pour servir des fichiers statiques et passer PHP à Apache

Le problème de l'utilisation d'Apache seul est qu'il ouvre une connexion et utilise php à chaque demande, même pour les fichiers statiques. Cela gaspille les connexions car Apache les garde ouvertes et lorsque vous avez beaucoup de trafic, vos connexions sont bloquées même si elles ne sont pas utilisées.

Par défaut, Apache écoute les demandes sur le port 80, qui est le port web par défaut. Tout d'abord, nous allons modifier nos fichiers conf et virtual hosts d'Apache pour écouter le port 8080.

Configuration d'Apache

httpd.conf

Définir KeepAlive sur off

ports.conf

NameVirtualHost *:8080
Listen 8080

Hébergement virtuel par 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>

Vous devez également installer mod_rpaf Ainsi, vos journaux contiendront les adresses IP réelles de vos visiteurs. Sinon, vos journaux auront 127.0.0.1 comme adresse IP d'origine.

Configuration de Nginx

Sous Debian, vous pouvez utiliser les dépôts pour installer mais ils ne contiennent que la version 0.6.33. Pour installer une version ultérieure, vous devez ajouter les paquets backports de Lenny.

$ nano /etc/apt/sources.list

Ajoutez cette ligne au fichier deb http://www.backports.org/debian lenny-backports main

$ nano /etc/apt/preferences

Ajoutez ce qui suit au fichier :

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

Exécutez les commandes suivantes pour importer la clé de backports.org afin de vérifier les paquets et de mettre à jour la base de données des paquets de votre système :

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

Maintenant, installez avec apt-get

apt-get install nginx

C'est beaucoup plus facile que de compiler à partir des sources.

Configuration des fichiers conf et serveur de 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/*;
}

Vous devez maintenant configurer votre hébergement virtuel Nginx. J'aime utiliser la méthode sites-enabled avec chaque sym d'hôte virtuel lié à un fichier dans le répertoire sites-available.

$ 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

Note :

Les paramètres de cache statique dans les fichiers suivants ne fonctionneront que si le plugin intégrateur de cache de proxy Nginx est activé.

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

Par site WordPress conf (Pour les sites multiples, vous n'aurez besoin que d'un seul serveur virtuel).

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-hébergée

Pour votre CDN hébergé par vos soins, il vous suffit de le configurer pour servir des fichiers statiques sans passer par le 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;
        }

    }

Maintenant, démarrez les serveurs

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

Les résultats de l'évaluation comparative

Sur Apache Bench, cette configuration peut théoriquement servir 1833,56 requêtes par seconde.

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

alt text

0voto

Halil Özgür Points 101

Cela ressemble à une configuration Apache standard, bien qu'il semble qu'une partie de celle-ci ait été supprimée car elle ressemble à du HTML.

Vous devez examiner ce qui se passe lorsque votre serveur répond lentement. Vous ne précisez pas les spécifications de votre serveur mais vous mentionnez qu'il est dédié et que 10k/jour devrait être facilement gérable.

  • Que montre le haut ?
  • Où se trouve le goulot d'étranglement ? CPU, mémoire, attente E/S ?
  • Combien de processus Apache sont en cours d'exécution ?
  • Combien de connexions sont affichées dans netstat ?

Je suppose que le CPU est probablement le goulot d'étranglement causé par PHP. L'utilisation d'APC et d'un plugin de mise en cache WP sont de bonnes méthodes pour atténuer ce problème, ce que vous avez déjà fait. Vous pouvez également essayer le modèle de processus "MPM" d'Apache au lieu de "Prefork". Assurez-vous que vous avez suffisamment de mémoire allouée à APC pour qu'il puisse mettre en cache vos scripts PHP et ne pas "manquer".

Cela pourrait aussi être MySQL - voyez si cela monopolise le CPU ou le disque.

Envisagez de désactiver le module mod_deflate si vous l'avez activé. Il améliore les temps de chargement, mais peut augmenter la charge du processeur. Cela peut valoir la peine d'essayer.

Utilisez un outil comme "siege" ou "ab" pour évaluer votre serveur et déterminer à quel moment il est ralenti.

Voici quelques-uns de mes favoris en matière d'optimisation des performances des serveurs 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/

Mais mon conseil d'origine reste le même : découvrez d'abord quel est le goulot d'étranglement ! Sinon, vous essayez aveuglément d'améliorer les performances (et bien sûr, l'amélioration des performances est toujours une bonne chose) mais sans savoir dans quel domaine concentrer votre attention.

0voto

Kit Sunde Points 2829

Activez également l'option statut du serveur et visitez-le pour savoir ce qui se passe.

Vous pouvez échanger des données. Avez-vous vérifié vmstat pendant que cela se produit ? 2 Go de RAM pour 80 MaxClients ne représentent que 25 Mo pour chacun d'entre eux (en supposant que la machine ne fait rien d'autre). La solution à ce problème est évidente : ajoutez de la RAM ou réduisez le nombre de MaxClients. Si la ligne de commande est lente à répondre lorsque vous redémarrez apache, c'est une indication de cette situation.

Il est également possible que vous nourrissiez certains clients mobiles (ou d'autres clients ayant des connexions lentes) avec des fichiers "volumineux", consommant ainsi tous les emplacements apache disponibles. Vous avez peut-être trop peu de MaxClients. En vérifiant l'état du serveur, vous saurez ce que chacun de ces clients fait à ce moment-là. Une solution pour cette situation est d'augmenter le nombre de MaxClients (mais cela pourrait aussi se transformer en la situation décrite ci-dessus). Une meilleure solution est d'installer un accélérateur HTTP en amont d'apache (une option gratuite est perlbal).

0voto

Chris Ballard Points 3125

Utilisation de mod_status est le moyen de voir ce qui se passe à l'intérieur des multiples instances d'Apache, mais veuillez noter que cela nuit vraiment aux performances. Il semble consommer de la mémoire et dans un cas, je n'ai pas été en mesure de diagnostiquer s'il était à l'origine de blocages de processus uniques dans une configuration de reverse-proxy-only où rien n'était servi directement. Ces blocages sont bien sûr signalés par les utilisateurs comme "le chargement de la page prend une éternité". Ils ne comprennent même pas la différence entre "il aurait fallu attendre 10 secondes de plus" et "ça ne finira jamais", car ils cliquent généralement sur "Stop" dans leur navigateur après quelques secondes (<10).

Vérifiez également si vous configurez le bon endroit (facile à voir en utilisant mod_status puisque vous voyez le nombre d'instances/processus). La configuration de base, au moins sous Ubuntu, comporte des sections ifdef'ed par mode MPM et il est facile de modifier le mode worker lorsque vous utilisez prefork (comme le suggère la sagesse conventionnelle à partir d'un sentiment flou que PHP n'est pas threadsafe).

Oh et surtout : Courez au sommet de en tant que root et regarder si les ressources sont au maximum. Mémoire, disque, CPU - vous verrez.

Une dernière : L'idée de désactiver le mod_deflate peut être bonne, même si votre configuration n'est pas sujette à l'erreur d'une information de longueur de contenu incorrecte qui fait que le navigateur attend des données "pour toujours", ce qui vous donne des rapports de "très lent" à "ne répond pas".

BTW : 10K pages livrées par jour plus les fichiers média sur cette machine ne devraient être un problème que si elles viennent toutes visiter en une heure.

0voto

Quelques conseils, surtout si vous hébergez beaucoup de fichiers multimédias :

  • Déplacez vos médias vers une instance Apache (ou mieux : nginx) dédiée. Pas de PHP, pas de modules, seulement un serveur http simple qui fournira les médias aussi vite que possible.
  • Cache, cache, cache ! Utilisez le plugin super cache sur wordpress. Il aide beaucoup.
  • Vérifiez votre configuration apache sur les en-têtes. Vérifiez que les images et autres médias "stables" ont un délai d'expiration fixé à une date éloignée et que votre apache renvoie un code HTTP 304 lorsque les clients le demandent.
  • Activez mod_deflate. Cela peut réduire les performances, mais les clients seront servis plus rapidement.

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X