AmazonLinux+nginx+php-fpmでwordpressの高速化する時の設定のチューニングについてもう少し調べたのでメモ

nginx

・worker_procceses

syntax :worker_proccesses number|auto;

default :worker_proccess 1;

context :main

nginxが生成するworkerproccessの数を指定。様々な要因によって最適な値は変わるが、目安としてはcpuのcore数。autoでcpuのcore数を自動検出。workerproccessの数を増やせば多くのacceessをさばけるようになる。

・worker_connections

syntax :worker_connections number;

default:512;

context:events

１つのworkerproccessがさばける接続数。ここでの接続はクライアントだけではなく、プロキシなどとの接続も含む。worker_rlimit_nofileの値を変更できないため、連動して変更する必要がある。

・worker_rlimit_nofile

syntax:worker_rlimit_nofile number;

default:-

context:main

workerproccessたちが同時に開けるファイルディスクリプタの最大数。OSの設定sys.fs.file-maxの値を超えられないので、これと連動して変更する必要あり。(ファイルディスクリプタとはファイルや標準入出力を識別するために用いる識別子)

・accept_mutex,accept_mutex_delay

排他制御に関わる設定らしい。

設定すると、場合によってはパフォーマンスが上がるらしいが、正直公式のドキュメント読んでもよくわからない。

reuseportを使うならこの設定はいらないらしい。

・sendfile,tcp_nopush

syntax:sendfile on|off;

default:off

context:http

linuxのsendfile apiを使う。カーネル空間内でファイルの読み込み送信が完了するので、効率よくファイルの送信ができるらしい。

syntax:tcp_nopush　on|off

default:off

context:http

sendingfileをonにしていると使える。linuxのオプションを使って、レスポンスヘッダとファイルの内容をまとめて送るようになるらしい。

・keepalive_timeout

syntax:keepalive_timeout　number

default :75

context:http

0を指定すると無効化。

一度確立したセッションを一定時間保持し再利用することで、セッション確立のオーバーヘッドを削減して効率化。

・open_file_cache

syntax:open_file_cache off| max=number [inactive=time]

default：off

context:http

ファイルのディスクリプタ、サイズ、タイムスタンプ、ディレクトリの存在情報、404などのエラー情報をキャッシュする。

max でキャッシュする最大数を指定。キャッシュがいっぱいになったあとはLRUで削除されていく。

inactiveで指定した秒数アクセスがなければ、キャッシュから削除（デフォルトは60s）

ファイル本体をキャッシュするわけではないので、パフォーマンスがあまりあがらないかも。

・tcp_nodelay

syntax：tcp_nodelay on|off

default:on

context:http

onなら高速ネットワークでパフォーマンスが向上する可能性がある。

本来、tcp_nodelayと、tcp_nopushは相反する動作をするが、nginxはこれらを併用可能な実装をしている

nopushでパケットの送信を遅延→nopush off→nodelayでフラッシュ

・listen

①backlog=number

クライアントからリクエストを送ると、まずosとtcpセッションを確立してから、サーバーにacceptされるらしいが、acceptできないほど接続数が多ければ、tcpセッションを保持したままソケットキューというキューに入れられる（ソケットキューはポートごとに作られる）

backlogでソケットキューの長さを指定。

ソケットキューの長さはosの方でも設定があって（net.core.somaxconn）、そちらのほうがbacklogより優先されるのでそちらも適宜書き換える。

http://u-kipedia.hateblo.jp/entry/2015/01/01/001135

https://qiita.com/nk_yohn3301/items/515733ed244ee3f35522

②fastopen=number

数字を設定するとonになる

数字はtcpセッション確立（3way handshake）が済んでいないリクエストを入れるキューの長さ

onにするとtcpセッション確立のオーバーヘッドを削減できる

公式のドキュメントにDo not enable this feature unless the server can handle receiving the same SYN packet with data more than once.と書いてあるけれどいまいちよくわからない…

③reuseport

複数のプロセスが1つのポートをバインド出来るようになるらしい

そしてカーネルがどのworkerプロセスにリクエストをふるか決めるようになり、レイテンシを下げ、パフォーマンスを向上させるらしい。

https://no-ne.ws/computer/773

公式ドキュメントによるとInappropriate use of this option may have its security implications.とのこと

・ssl_session_cache

syntax： ssl_session_cache　off|none|builtin[:size]|shared:name:size

default:none

context:server

tlsセッション確立のオーバーヘッド削減に役立つ

offで完全にオフ

noneでオフなんだけど、クライアントに再利用されるかもと通知するらしい

builtin opensslに組み込まれているキャッシュ。一つのworkerプロセスにしか使われない。sizeを指定しないと、20480件をキャシュするらしい。公式ドキュメントによると、メモリのフラグメンテーションを起こしうるらしい。

shared 全てのworkerプロセスでキャッシュが共有される。size1Mあたりおよそ4000セッション保存。キャッシュに名前をつけなければならない。複数のvirtual serverでキャッシュの名前は共有される。

・ssl_session_timeout

ssl_session_timeout　time

default:5m

context:server

セッションのキャッシュの保持時間の設定

・ssl_session_tickets

syntax:ssl_session_tickets on|off

default:off

context:server

セッション情報を暗号化してクライアントに送り、それを用いることでtlsセッション確立のオーバーヘッド削減に役立つ

https://techblog.yahoo.co.jp/infrastructure/ssl-session-resumption/にはcacheとticketsはきちんと運用すればセキュリティ上問題ないことが書いてある

・ssl_stapling

syntax　ssl_stapling on|off

default:off

context:server

・ssl_stapling_verify

syntax:ssl_stapling_verify on|off

default:off

context:server

・ssl_trusted_certificate

公式ドキュメントによるとIf the ssl_certificate file does not contain intermediate certificates, the certificate of the server certificate issuer should be present in the ssl_trusted_certificate file.とのこと。よくわからない…

・resolver

syntax:resolver　ip [valid=time]

oscpレスポンダのip指定。validで有効時間指定。

・resolver_timeout

resolver_timeout time

oscpレスポンダへの問い合わせのタイムアウト指定。

本来tlsセッションをする時に認証局に問い合わせをして証明書が有効か確認するが、認証局が持っているoscpレスポンダというサーバーに問い合わせて確認することで一定時間有効か確認せずに済むようになりtlsセッション確立のオーバーヘッド削減に役立つ

https://rms-digicert.ne.jp/howto/basis/enabling-ocsp-stapling.html

・ssl_buffer_size

syntax ssl_buffer_size size

default:16k

context:server

tlsは一定サイズごとに通信暗号化するがデフォルトの16kだと大きすぎて、通信が遅くなる原因になるらしい。

自分が見たサイトでは4kを推奨していた。TTFB改善に役立つらしい。

・スレッドプール

http,server,locationのいずれかのcontextでaio threads;と書けば良い。 詳しい仕組みは、 https://fa-works.com/blog/thread-pools-boost-performance-9x

OS

・sys.fs.file-max

OS全体で使えるファイルディスクリプタの数。

・net.core.somaxconn

ソケットキューの長さ指定

・sys.net.tcp_fastopen

linuxでのtcpfastopenの設定

よくわからないが3を設定すると、クライアント側、サーバー側で有効になるため3がいいらしい。

http://asnokaze.hatenablog.com/entry/2017/05/09/223534 によると、時折謎な挙動をすることがあるらしい

https://html5experts.jp/jxck/3529/

http://kernhack.hatenablog.com/entry/2013/05/25/115634

・net.ipv4.tcp_fin_timeout

tcpプロトコルの細かい部分を理解していないのでよくわからないが、低すぎると問題になるらしい。

http://server.etutsplus.com/kernel-setting-tcp-fin-timeout/

プラグイン

headcleaner 不要なタグ、空白を削除したり、タグをまとめたり、CSSを圧縮したりするプラグイン。高速化に役立つと思われる。

unveil lazyload 画像の遅延読み込み。スクロールして画像の近くに来たら読み込む。読み込みデータ量の削減、httpリクエスト数の削減が出来るため、高速化に役立つと思われる。

php-fpm

php-fpmの設定ファイルで

pm = dynamic
pm.max_children = 8
pm.start_servers = 2
pm.min_spare_servers = 2
pm.max_spare_servers = 4
pm.max_requests = 500

とするのがある程度一般的らしい。

max_children 同時に実行可能な子プロセス数

start_servers プロセス開始時に生成される子プロセス数

min_spare_server 待ち状態の子プロセスの最小数

max_spare_server 待ち状態の子プロセスの最大数

https://blog.xn--krsgw–n73t.com/blog/diary/php-fpm