カスタムメトリクスを使用してキャッシュヒットを追跡し、パフォーマンスを向上

AppSignal を使用するアプリを実行しているすべてのサーバーは、サンプルとメトリクスのコレクションを 30 秒ごとに Push API に送信します。

各リクエストには、データがどのアプリから来たかを判断するために使用するキーがあります。そのためには、データベースにクエリを実行して、受信リクエストごとにアプリを見つける必要があります。毎月 300 億件のリクエストがあるため、私たちは AppSignal を高速化するためにクエリの数を減らす方法を常に模索しています。

データベース クラスター上のクエリの数を減らすためにキャッシュを実装しました。データベースからアプリを取得するたびに、それを Memcached に 1 分間保存します。この変更を実稼働環境にデプロイした後、さらにのことを行っていることがわかりました。 以前よりもクエリが増えました。キャッシュが頻繁に無効化されるようです。どこでそれが起こったのかを調べるために、キャッシュが不適切に無効化された場所を見つけるためのカスタム指標をいくつか追加しました。

プッシュ処理時間が更新されたときや、新しい名前空間を検出したときなど、キャッシュを無効にする場所がいくつかあります。

これらのキャッシュ無効化のどれが原因であるかを判断するために、複数のカウンターを追加しました。この例では、app.cache.invalidate をインクリメントします。 検証の合計数をカウントするカウンター。app.cache.invalidate_push_time などの特定のキーを使用します。 および app.cache.invalidate_namespaces 特定の無効化については。

上記のカスタム メトリクスを追加すると、時間の経過に伴うキャッシュ ヒットをグラフ化することができました。どのキャッシュ キーがクエリの増加を引き起こしたかはすぐに明らかになりました。 app.cache.invalidate_namespaces キーはリクエストごとに無効になりました。

キャッシュ可能なリクエストの総数は app.cache.maybe としてカウントされます。 .

この問題の修正をデプロイした後、アプリの名前空間が更新されない限り、無効化の数はゼロに減少しました。

カスタム メトリクスを追加すると、どこで、いつ、どのくらいの頻度で何が起こっているかを理解しやすくなります。この場合、キャッシュの無効化の数を把握し、それを読みやすいグラフで表示することで、問題をすぐに見つけることができました。特定の値をインクリメントしてダッシュボードを作成するには、数行のコードが必要なだけです。

カスタム メトリクスについてご質問がある場合、またアプリケーションでのカスタム メトリクスの設定をお手伝いできるかどうかお知らせください。喜んでお手伝いさせていただきます!

ロバート・ビークマン

ロバートは共同創設者として、私たちの最初のコミットを書きました。彼は私たちのサポートのロールモデルでもあり、コードの細かい詳細についてすべて知っています。旅行と写真 (同時に)。

Robert Beekman によるすべての記事