web-dev-qa-db-fra.com

Optimisez Nginx + PHP-FPM pour des temps de réponse plus courts (pour les adserving Openx)

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.

20
Fariz

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.

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

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

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

  4. 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";
    }
    
  5. 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. 

70
KBeezie

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.

6
zmf

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.

4
user145633

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

3
Skaag Argonius

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.

1
Todd

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/

0
p4guru