サーバー側で304(Not Modified)を解決するキャッシュプログラムの仮称
Githubレポジトリ: https://github.com/towasys/octpepper
キャッシュの実装が面倒(な予感)なので、puppeteerを使って、Chromiumのキャッシュ機構に乗っける(ことができるといいなぁ)。
Chromiumじゃなくても良さそうになってきた。
サーバー側で304(Not Modified)を解決するキャッシュプログラムの仮称
Githubレポジトリ: https://github.com/towasys/octpepper
キャッシュの実装が面倒(な予感)なので、puppeteerを使って、Chromiumのキャッシュ機構に乗っける(ことができるといいなぁ)。
Chromiumじゃなくても良さそうになってきた。
何もかもをキャッシュしたのは良くなかった。
そもそもブラウザのキャッシュが効きすぎている。無効化してみよう。
Service WorkerでCache APIを使う仕組みが良く分かっていない。難しい。
Service Workerで、オフラインの時だけキャッシュを使うようにした。
DBのキャッシュを多くすれば、nginxのキャッシュは不要かと思ったが、利用者に近いところにキャッシュがあったほうがレスポンスが高くなるだろうか、そういった意味ではデータベースキャッシュを多くするよりもnginxのキャッシュを増やすほうが良いと思われる。
もちろんコストを勘案して総合的に考える必要があるし、経験的な判断も必要になるだろう。
サーバーに負荷がかかるようになってきたらキャッシュを有効化したい
理由は忘れたけどnginxのキャッシュを無効化した。悪さしてた気がする。「システムをアップデートしても、反映されるまで時間がかかるのがもどかしい」みたいな理由だったと思う。
レスポンスの向上につながるのではないかと思いnginxのキャッシュを試してみている。残念ながら現状ではレスポンスの向上にはつながらなかったし、設定がうまくいっていないのかHIT率が悪い。