J'utilise actuellement Nginx + PHP-FPM pour la diffusion d'annonces sur OpenX. Actuellement, mes temps de réponse sont horribles, même pendant les périodes de faible charge. Cependant, mes ressources en matière de processeur et de mémoire sont correctes. Je n'arrive donc pas à comprendre le goulet d'étranglement.
Ma configuration actuelle pour nginx et php-fpm est:
worker_processes 20;
worker_rlimit_nofile 50000;
error_log /var/log/nginx/error.log;
pid /var/run/nginx.pid;
events {
worker_connections 15000;
multi_accept off;
use epoll;
}
http {
include /etc/nginx/mime.types;
access_log /var/log/nginx/access.log;
sendfile on;
tcp_nopush off;
keepalive_timeout 0;
#keepalive_timeout 65;
tcp_nodelay on;
gzip on;
gzip_disable "MSIE [1-6]\.(?!.*SV1)";
gzip_comp_level 2;
gzip_proxied any;
gzip_types text/plain text/html text/css application/x-javascript text/xml application/xml application/xml+rss text/javascript;
include /etc/nginx/conf.d/*.conf;
include /etc/nginx/sites-enabled/*;
}
server {
listen 80;
server_name localhost;
access_log /var/log/nginx/localhost.access.log;
# Default location
location / {
root /var/www;
index index.php;
}
## Parse all .php file in the /var/www directory
location ~ .php$ {
fastcgi_pass localhost:9000;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME /var/www$fastcgi_script_name;
include fastcgi_params;
fastcgi_param QUERY_STRING $query_string;
fastcgi_param REQUEST_METHOD $request_method;
fastcgi_param CONTENT_TYPE $content_type;
fastcgi_param CONTENT_LENGTH $content_length;
fastcgi_ignore_client_abort off;
}
PHP-FPM:
rlimit_files = 50000
max_children = 500
Je n'ai inclus que les paramètres PHP-FPM que j'ai modifiés pour PHP-FPM.
Quelqu'un at-il des conseils pour l’optimiser afin de pouvoir répondre à plus de demandes? Je vois des temps de réponse horribles en ce moment.
Tout d’abord, beaucoup trop de travailleurs et des limites excessivement élevées. Le nombre maximum de travailleurs pour php-fpm à lui seul gâcherait un peu votre serveur. Déboucher les limites sur un serveur n'accélérera pas forcément la vitesse, mais peut en réalité avoir l'effet inverse.
Nombre de travailleurs: 20 n’a guère de sens si vous n’avez pas de processeur/machine à 20 ordinateurs centraux, vous causez en fait un effet négatif car les travailleurs subiront un échange de contenu excessif. Si vous utilisez un processeur dual core, 2 travailleurs devraient suffire.
Connexions des travailleurs: Encore une fois, le simple fait de jeter une limite dans les cieux ne résout pas vos problèmes. Si votre sortie ulimit -n est quelque chose comme 1024, alors vos connexions de travail devront être définies à 1024 ou moins (peut-être même 768), il est peu probable que vous ayez 2 x 1024 connexions simultanées, notamment avec PHP.
L'emplacement racine et les paramètres PHP, reportez-vous à http://wiki.nginx.org/Pitfalls , cela fonctionne mieux si vous mettez votre directive racine au niveau du serveur {}, pas au niveau de l'emplacement. Une fois que vous avez fait cela, vous pouvez utiliser $ document_root $ fastcgi_script_name car la valeur SCRIPT_FILENAME en tant que $ document_root sera automatiquement propagée aux blocs d’emplacement situés en dessous.
Vous voudrez peut-être gérer les fichiers statiques directement, autrement dit:
location ~* \.(ico|css|js|gif|jpe?g|png)$ {
expires max;
add_header Pragma public;
add_header Cache-Control "public, must-revalidate, proxy-revalidate";
}
Utilisez un accélérateur PHP, à savoir APC (avec apc.enabled = 1 dans php.ini) ou XCache, et faites attention à vos paramètres php, tels que memory_limit. Par exemple, si vous ne disposez que de 2 Go de béliers, il est peu logique d'autoriser 500 ouvriers avec une limite de 128 Mo chacun. C'est particulièrement vrai si vous utilisez également d'autres services sur votre serveur.
Serait également utile de mettre:
access_log off;
Comme je suppose que vous ne vous souciez pas vraiment de la génération de journaux sur ces demandes.
Vous devriez certainement réduire le nombre de travailleurs car je doute que vous ayez 20 cœurs/processeurs ..__ De plus, j'examinerais votre serveur de base de données, il y a de grandes chances que le problème existe.
De plus, vous avez augmenté le worker_rlimit_nofile
à 50000
. J'espère que vous savez que le système d'exploitation définit généralement la limite à 1024 (valeur par défaut). Vous pouvez essayer de demander quelle est la limite actuelle en tapant ulimit -n
.
Vous pouvez augmenter la limite absolue de NOFILE (nombre de fichiers ouverts) en exécutant la commande ulimit -n 50000
dans init.d ou visitez cette autre question sur stackoverflow pour savoir comment utiliser limits.conf
pour définir de manière permanente des limites pour l'ensemble du système.
Pousser vraiment les performances au maximum avec nginx et php5-fpm est un art. Il faut vraiment comprendre le type de contenu que vous servez.
Par exemple, je ne vois aucune utilisation de try_files, ni aucune sorte de mise en cache dans votre configuration. Savez-vous que nginx est livré avec le support intégré de memcache? Vous pouvez mettre en cache des images et html/css, ainsi que des pages php. Si vous vous souciez surtout des clics, ces clics seront toujours comptabilisés même si les affichages ne le sont pas.
Mettez vos bannières dans un montage tmpfs, ne vous connectez pas aux journaux access_log ou error_log, désactivez les modules inutiles en php, utilisez une version récente de mysql, utilisez innodb pour réduire le verrouillage des tables, jouez avec la méthode de vidage de innodb pour réduire le disque écrit, augmentez le nombre maximum de tables de mémoire dans mysql afin de réduire la création de fichiers temporaires sur le disque lorsque des jointures sont demandées via SQL, etc.
Nginx n'est qu'une partie d'une formule très volumineuse et complexe. Je n'ai même pas mentionné les paramètres du noyau pour optimiser les performances de la pile TCP et de la carte réseau, l'utilisation de Swap, l'utilisation de la mémoire ou la compression HTML/CSS gzip que vous seriez peut-être en train de servir via OpenX (si vous êtes).
Et oui, comme d’autres précédents, vos paramètres semblent excessifs et montrent un manque de compréhension des concepts d’optimisation de base. En d'autres termes, engagez un professionnel :-)
avez-vous 20 processeurs ou cœurs sur votre machine? essayez peut-être aussi des événements avec la valeur par défaut pour votre système d'exploitation ... peut-être davantage de processus fcgi au lieu de plus de nginx ... commencer par 2 à 4 travailleurs nginx suffit.
Certainement aussi bien les travailleurs que les gens ont mentionné. Personnellement, je préfère xcache à APC pour la mise en cache php opcode. Vous devriez vérifier la configuration dans le script d’installation nginx/php-fpm modifié centmin auto bash Shell http://vbtechsupport.com/796/