Optimisez apache pour 10K + vues wordpress par jour sur 2 Go de RAM E6500 CPU


10

J'ai un serveur dédié avec apache / php sur ubuntu servant 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écupérer.

Heres ma config ce que je fais 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/

Réponses:


23

Mes performances WordPress et pile de cache

Il s'agit d'une excellente pile de performances WordPress pour un serveur unique ou VPS de gamme basse à moyenne. Je classe le milieu de gamme comme un seul cœur avec environ 1 Go de mémoire et des disques assez rapides.

Sur votre box, cela serait capable de diffuser plus de 10 000 pages vues par heure

Pile de serveur

  • Linux - Soit Debian Lenny ou Ubuntu
  • Nginx - Configuré comme cache de fichiers statiques de proxy inverse
  • 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 une mémoire mmap et une taille shm d'au moins 128 Mo

Pile de plug-in de performance WordPress

  • Intégrateur de cache proxy Nginx
  • W3 Total Cache - Définissez le cache de page sur le disque amélioré, réduisez le volume sur le disque et l'objet et la base de données sur APC.
  • CDN auto-hébergé - Créez 4 alias cname qui pointent vers un domaine sur le serveur configuré juste pour servir un fichier statique

Avec W3 Total Cache, nous utilisons le disque pour le cache de page et la réduction car Nginx servira nos fichiers statiques très rapidement.

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

Le problème avec l'utilisation d'Apache seul est qu'il ouvre une connexion et frappe php à chaque demande, même pour les fichiers statiques. Cela gaspille les connexions car Apache les gardera ouvertes et lorsque vous avez beaucoup de trafic, vos connexions seront 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. Nous allons d'abord apporter des modifications à nos fichiers Apache conf et virtual hosts pour les écouter sur le port 8080.

Apache Config

httpd.conf

désactiver KeepAlive

ports.conf

NameVirtualHost *:8080
Listen 8080

Hôte 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 pour que vos journaux contiennent les adresses IP réelles de vos visiteurs. Sinon, vos journaux auront 127.0.0.1 comme adresse IP d'origine.

Nginx Config

Sur Debian, vous pouvez utiliser les référentiels pour installer, mais ils ne contiennent que la version 0.6.33. Pour installer une version ultérieure, vous devez ajouter les packages de rétroportages 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 pour vérifier les packages et mettre à jour la base de données de packages de votre système:

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

Installez maintenant avec apt-get

apt-get install nginx

C'est beaucoup plus facile que de compiler à partir de la source.

Config Nginx et configuration des fichiers serveur

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 des sites activés avec chaque sym hôte v lié à un fichier dans le répertoire des sites 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

Remarque:

Les paramètres de cache statique dans les fichiers suivants ne fonctionneront que si le plug-in d'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 conf WordPress (pour les sites multiples, vous n'aurez besoin que d'un seul hôte)

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

        }

Configuration CDN auto-hébergée

Pour votre configuration CDN auto-hébergée, vous n'avez qu'à la configurer pour servir des fichiers statiques sans le 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;
        }

    }

Maintenant, démarrez les serveurs

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

Les résultats de référence

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

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

texte alternatif


Vous mentionnez que nginx gère les fichiers statiques et apache gère les fichiers php, mais dans le bloc des fichiers statiques, vous avez "proxy_pass wordpressapache ;". Cela ne signifie-t-il pas qu'Apache gère les fichiers statiques?
srchulo

0

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

Vous devez rechercher ce qui se passe lorsque votre serveur répond lentement. Vous ne dites pas les spécifications de votre serveur mais vous mentionnez qu'il est dédié et que 10k / jour devraient être facilement manipulés.

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

Devinez, le CPU est probablement le goulot d'étranglement provoqué par PHP. Utiliser APC et un plugin de mise en cache WP sont de bonnes méthodes pour atténuer cela, 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 d'avoir suffisamment de mémoire allouée à APC pour qu'il puisse mettre en cache vos scripts PHP et ne pas «manquer».

Il pourrait également s'agir de MySQL - voir si c'est monopoliser le processeur ou le disque.

Envisagez de désactiver mod_deflate si vous l'avez activé - cela offre des avantages pour les temps de chargement, mais peut augmenter la charge du processeur. Cela pourrait valoir la peine d'essayer.

Utilisez un outil comme «siège» ou «ab» pour comparer votre serveur et déterminer à quel moment votre serveur ralentit.

Voici quelques-uns de mes signets de l'optimisation des performances du serveur 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 bonne) mais sans savoir sur quel domaine concentrer votre attention.


0

Activez également le module d' état du serveur et visitez-le pour savoir ce qui se passe.

Vous échangez peut-être. Avez-vous vérifié vmstat pendant que cela se produit? 2 Go de RAM pour 80 MaxClients n'est que de 25 Mo pour chacun (en supposant que la boîte ne fait rien d'autre.) Vos MaxClients peuvent être trop élevés. La solution est évidente: ajoutez plus de RAM ou moins 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 alimentiez à la cuillère certains clients mobiles (ou d'autres clients sur des connexions lentes) avec de «gros» fichiers, consommant ainsi tous vos emplacements Apache disponibles. Vous avez peut-être trop peu de MaxClients. La vérification de l'état du serveur vous indiquera ce que chacun de ces clients fait à ce moment-là. Une solution à cette situation consiste à augmenter MaxClients (mais cela pourrait également se transformer en la situation ci-dessus.) Une meilleure solution consiste à installer un accélérateur HTTP devant apache (une option gratuite est perlbal). Si votre ligne de commande est normale vitesse lorsque vous redémarrez apache, c'est une indication de cette situation.


0

L'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 affectera vraiment les performances. Il semble consommer de la mémoire et dans un cas, je n'ai pas pu diagnostiquer si c'était la cause des blocages de processus unique dans un paramètre de proxy inverse uniquement où rien n'était servi directement. Ceux-ci sont bien sûr rapportés par les utilisateurs comme "il faut une éternité pour charger la page". Ils ne comprennent même pas la différence entre "il aurait fallu 10 secondes de plus pour attendre" et "cela ne se terminera jamais" car ils frappent généralement Stop dans leur navigateur après quelques (<10) secondes.

Vérifiez également si vous configurez le bon emplacement (facile à voir en utilisant mod_status puisque vous voyez la quantité d'instances / processus). La configuration de stock au moins sous ubuntu a des sections ifdef'ed par mode MPM et il est facile de modifier le mode de travail lorsque vous exécutez prefork (comme suggéré par la sagesse conventionnelle à partir d'un sentiment flou que PHP n'est pas threadsafe).

Oh et surtout: courez au sommet en tant que root et surveillez les ressources maximales. Mémoire, disque, CPU - vous verrez.

Un autre: L'idée de désactiver mod_deflate peut être bonne, bien que votre paramètre ne soit pas sujet à l'erreur d'informations de longueur de contenu incorrectes, ce qui oblige le navigateur à attendre les données "pour toujours", vous donnant des rapports de "mort lent" à "ne répond pas".

BTW: 10 000 pages livrées par jour plus les fichiers multimédias sur cette machine ne devraient être un problème que s'ils viennent tous visiter en une heure.


0

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

  • Déplacez vos médias vers une instance Apache dédiée (ou mieux: nginx). Pas de PHP, pas de modules, seulement un serveur http nu qui livrera les médias le plus rapidement possible.
  • Cache, cache, cache! Utilisez le plugin super cache sur wordpress. Ça aide beaucoup.
  • Vérifiez votre configuration apache sur les en-têtes. Vérifiez que les images et les autres médias "stables" ont une heure d'expiration définie sur une date éloignée et que votre apache renvoie un code HTTP 304 à la demande des clients
  • Activez mod_deflate. Il peut réduire les performances des clients sera plus rapidement servi.
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.