t_wの輪郭

Feedlyでフォローするボタン
化高速こうそくか
t_wの輪郭 を高速化『t_wの輪郭』でnginxでキャッシュして高速化する失敗の高速化デプロイを高速化サービスが高速化すると、利用者の利用頻度が増える検索高速化デライト高速化高速化する余地500倍の高速化高速化すると運用が変わる『運用に困っていた重いバッチを高速化したらそもそもの運用が変わった話 - Speaker Deck』

サーバーに負荷がかかるようになってきたらキャッシュを有効化したい

2022年9月？日

理由は忘れたけどnginxのキャッシュを無効化した。悪さしてた気がする。「システムをアップデートしても、反映されるまで時間がかかるのがもどかしい」みたいな理由だったと思う。

2022年5月17日

レスポンスの向上につながるのではないかと思いnginxのキャッシュを試してみている。残念ながら現状ではレスポンスの向上にはつながらなかったし、設定がうまくいっていないのかHIT率が悪い。

t_wの輪郭 を高速化

2022/8/21 16:19:00

2022年8月21日

複数回発行されているSQLクエリを1回にまとめることで高速化を図った。
結果としてはDOMContentLoadedが600ms程度から550ms程度になり、僅かに高速化された。

リンク先のコンテンツ量が乏しいリンクと前景を無効化する処理を、アクセスされた時ではなく事前に処理するようにした。
DOMContentLoadedが550msから130msに高速化された。満足のいく結果になった。

2022年8月10日

若干サイトがもたつく気がする。度重なる機能追加で重たくなった可能性がある。実行速度の測定をしてみる。
開発環境でhtmlが渡されるまでを測定してみたところ、以下の結果となった。
開発環境：162, 145, 156, 153, 150 [ms]→平均153.2 [ms]

サーバー側のプログラムを触ってみたがそれほど高速化できなかった

Amazon Mobile Popoverの読み込み待ちで描画が遅れている。削除した。

そろそろCDNが使いたくなってきた。ただ、CDNを使うとサーバーまでアクセスが届かないので

一旦の対応としてGoogle AnalyticsをCookie無しでも動くようにした。

2022年5月4日

ローカルで動かしているときは問題ないのに、サーバで動かすとリソース（特にfavicon.svg）の取得に謎の待機時間が生じていた。600msとかの待機時間が発生していた。

nginxの設定でlimit_req_zoneが
limit_req_zone $binary_remote_addr zone=limit_req_by_ip:10m rate=1r/s;
にしてしまっていたのを、
limit_req_zone $binary_remote_addr zone=limit_req_by_ip:10m rate=10r/s;
に変更した。

秒間1アクセスまでに律速されていたのが、秒間10アクセスまで許容するようにした。
良く調べずに使うからこうなる。


調べてる途中でDBが遅いのかもしれないと思い、CREATE INDEXした。効果はなかった。

Google であった本当の話。ある日エンジニアリングチームが Google マップの大幅なレイテンシーの改善を行った。事前に告知もしなかったしブログにも書かなかった。秘密裏にこっそりとローンチしたのである。すると最初の数日間で利用のアクティビティグラフが大幅に（しかも継続的に）向上した。心理状態の大きな変化が起きたのだ！