ISUCON14の延長戦をやってます
以下の記事の続きです。
前回は通知エンドポイントのひとつである、椅子の通知エンドポイントを高速化しました。 今回はもうひとつの通知エンドポイントにインメモリキャッシュを導入します。
なお、最終的なコードは以下のリポジトリで公開しています。
ユーザーの通知エンドポイントレスポンスをキャッシュする
前回と同様、レスポンスで返す情報のキャッシュを試みます。 このエンドポイントではユーザーがリクエストしているライドの情報、ライドに割り当てられた椅子の情報などを返しています。 椅子の情報をキャッシュしていくのは少し骨が折れそうだったので、ライドの情報に限定してキャッシュしてみました。
完全な差分は以下のPull Requestのとおりです。
実装に関してはほぼほぼ前回の修正と同様です。効果が大きかった変更も同様で、ライドをリクエストしてないユーザーへのレスポンスを高速に返せるようになりました。
// キャッシュからライド情報を取得 rideMapByUserIDMutex.RLock() rideFromMap, ok := rideMapByUserID[user.ID] rideMapByUserIDMutex.RUnlock() if !ok { writeJSON(w, http.StatusOK, &appGetNotificationResponse{ RetryAfterMs: 30, }) return }
まとめ・次回予告
前回に引き続き、通知エンドポイントのレスポンスをキャッシュすることで高速化を試みました。 ベンチマークの結果はおよそ43,000点！本戦終了時のスコア換算だと6位相当です！すごい、うおおお！
4.3万点まできた。現在26位 pic.twitter.com/xssxpcrK9c
— ふるさっくす (@furusax) 2024年12月30日
いよいよネタが尽きてきた……が、ユーザーの通知エンドポイントを眺めていたら気になる箇所が出てきました。次回はそこの改善に取り組みます。つづく。
