Conseils nécessaires – Comment suivre le problème de performance nginx-docker-rails

Mon application Rails est déployée sur Amazon Beanstalk élastique à l’aide de Docker. Les requêtes Web sont acheminées vers un serveur Web nginx qui les transmet au serveur de rails minces résidant dans le docker. Quelque part sur le chemin, il y a un goulot d’étranglement. Une fois toutes les 50 demandes (ou presque), je vois que nginx signale une durée de service supérieure à x40 par rapport au moment où les rails réduisent les rapports du serveur.

voici un exemple:

NGINX (7490ms):

146.185.56.206 – silo [18 / Mar / 2015: 13: 35: 55 +0000] “GET /needs/117.json?iPhone HTTP / 1.1” 200 2114 “-” “Mozilla / 5.0 (Macintosh; Intel Mac OS X 10_10_2) AppleWebKit / 537.36 (KHTML, comme Gecko) Chrome / 40.0.2214.115 Safari / 537.36 ” 7.490 7.490.
HTTP / 2 force redirection nginx HTTP à HTTPS brise le comportement attendu
Lucee 5, Nginx et Docker Compose ne pas trouver d’exemple de fichier index.cfm
link_to supprime le port du site hébergé dans le conteneur
NGINX comme proxy WebSocket avec Docker
Comportement bizarre du panneau wp-admin de WordPress

THIN (serveur de rails): 171ms

2015-03-18 13: 35: 48.349 méthode [INFO] = chemin d’access GET = / needs / 117.json format = contrôleur json = nécessite une action = affiche l’état = 200 durée = 171.96 vue = 109.73 db = 29.20 heure = 2015-03 -18 13:35:47

Quelqu’un peut-il fournir des conseils sur la façon de résoudre une telle situation? Comment trouver la source de la différence de temps de réponse? Je suppose que ce pourrait être nginx ou docker ou thin ou linux.

On dirait que l’un des processus minces est en train de faire une lourde tâche et que nginx envoie toujours des requêtes à celui qui est occupé. S’il y avait un problème de mise en queue dans Thin, le traitement de la demande prend peu de temps, mais plus longtemps pour atteindre le haut de la queue. Donc, vérifiez d’abord les autres demandes avant ou autour de cette demande.

Deuxièmement, si vous utilisez upstream pour servir ( http://nginx.org/en/docs/http/ngx_http_upstream_module.html ), vous pourriez apparemment avoir entre autres $ upstream_response_time et essayer de le connecter.

Troisièmement, vous pouvez également essayer de reproduire une configuration similaire dans dev / qa et essayer un test de résistance. Si vous parvenez à le reproduire de manière cohérente, vous pouvez voir le nombre de requêtes sur chaque queue (par exemple, http://comments.gmane.org/gmane.comp.lang.ruby.unicorn.general/848 ).