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 [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>
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/
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.
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.
la source
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.
la source
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.
la source
Quelques conseils, surtout si vous hébergez beaucoup de fichiers multimédias:
la source