サイトルートのレスポンスを見た時１秒とか３秒になっていて、
もうちょっと早くしたいなーと色々試行錯誤してみた。
このサイトは、App Service 上で動いているので、あまり極端なことをするような環境ではないのは確かですが、
やはりリソースをちゃんと使いたい・・・
.user.ini
App Service で動いているので、
.user.ini をサイトルートに配置すると機能してくれる。
ここで、以下の内容を追加した。
memory_limit = 512M
mysqlnd.mempool_default_size=64000
mysqlnd.net_read_buffer_size=131072
PHPが扱えるメモリ上限を512Mまで引き上げて、mysql 接続のバッファサイズを拡張した。
正直、これで体感するほど早くなったという感じはなかった。
使える設定は、user.ini で可能なもののみとなる。
php.ini ディレクティブのリスト
extensions.ini
App Service の機能としてphp.ini を読み込ませる機能を教えてもらった。
how-to-change-the-built-in-php-configurations
PHP_INI_USER、PHP_INI_PERDIR、PHP_INI_ALL 構成設定の変更
App Service のアプリケーション設定より、変数として「PHP_INI_SCAN_DIR」というキーに対して「d:\home\site\ini」を設定した。
アプリの再起動が必要になるが、ほとんどの設定が可能になる。
ほかにも、追加の拡張機能を読み込ませることや
独自のランタイムを読み込ませることもできるようだ。
plugin
WordPress 側のプラグインをいくつか入れて、いくつか止めた。
- Autoptimize
- wp-super-cache
SNS共有は、ローディングのわりに使う頻度がほとんどないから。
動作の軽い、Jetpack のものに置き換えた。
wp-config.php
PHPに割り当てられるメモリを増やしたため、こちらのメモリの割り当てをぐっと増やした。
define('WP_MEMORY_LIMIT', '64M');
define('WP_MAX_MEMORY_LIMIT', '128M');
Azure Database for MySql
試行錯誤してみたものの、そもそもこれがボトルネックではないので
変化はほとんどなかった。
また、PaaSという特性上、DBのすべてのパラメーターを設定することはできない。
（レプリケーションやインスタンスそのものは、マネージドであるためと考えれば理解しやすい）
App Service
- php 7.2 に設定
- HTTP 2.0 有効
で、気持ち早くなった。リクエスト数が多いと、HTTP 2.0 は有利に働いていた。
当然単発のリクエストが劇的に向上することはなかった。
いくつかのプラグインで、エラーがあったためハックした。 - facebook にエラーになる構文
- DB 接続のSSL 有効化定数
上記はコメントアウトした
元からの設定として、以下のようにしている。
– 常時接続モード有効
– 関係のないランタイムは「なし」
結果
上記色々試行錯誤したところ
キャッシュのパワーが圧倒的で、有効な状態であればリクエストあたり、100ms 以下で通信完了している。
リクエストする数を統合していくことで、全体の読み込み完了時間は大幅に短縮された。
体感では、元が５秒程度だったとき、１秒以内と、満足いくの結果が出た。