概要
- 現状
- GROWI v3.7.2 現在では全ユーザーの情報をブラウザ上にキャッシュとして保有している
- ページ表示時の閲覧ユーザー表示に用いるユーザーアイコンやユーザーネームなどの情報は、サーバーから送られてきたユーザーid を元にキャッシュから情報をとってきている
- ユーザーキャッシュの更新は、過去15分にキャッシュが更新されてない場合に走る
- 問題点
- 全ユーザーのキャッシュがあることがいけてない
- ブラウザ単位での初回ログイン時に全ユーザーの情報を拾ってくる処理をしているが、ユーザー数が膨大な組織の場合負荷が重くなり表示に時間がかかる
- キャッシュの更新は15分おきに発火しており、ユーザーが情報更新した際最長で15分間は反映されない
ユーザーキャッシュの利用箇所
- PageHistory.jsx ないの revision.author
- UserPictureList.jsx 内のユーザーアイコンおよびユーザーネーム表示
- seen-user-list, liker-user-list で使用
改善案
案1. ユーザーキャッシュを廃止し、毎回必要なユーザー情報のみサーバーからとってくるようにする
- 二つの問題点は解決
- コストも少なめ
- useridリストをとってくる箇所に populate 付け足せばできそう
懸念点
- ページアクセス時、サーバー側でのpopulate処理(ページ>ユーザ>画像)に時間がかかる
- 特に足跡数が多いページの表示時に毎回時間がかかるのでは
案2. ユーザーキャッシュを廃止し、mongo DB のembed機能を利用し、DB自体にキャッシュをおくようにする
懸念点
- ユーザー情報更新時に処理が重くなる(revision author, bookmark or seen したページを探しドキュメント更新)
案3. キャッシュからとったデータを一時的に表示しておき、裏でキャッシュ更新の是非を確認し必要であれば更新して表示するようにする
懸念点
案4. ユーザーキャッシュ自体は残すが、全ユーザーではなく、必要に応じたユーザーのみとってくる
- 要はキャッシュの運用方法の変更
- 初回キャッシュ取得という概念がない
- ページ閲覧画面アクセス時の挙動
- そのページの revision.author ユーザー、いいねユーザー、足跡ユーザーのユーザーidリストは今まで通り populate せずに持ってくる
- idリストに対し、キャッシュにユーザーがある場合はそこからデータを取得
- キャッシュにユーザーがない場合は、裏でサーバー側にユーザー（プロ画はpopulate)のデータ取得のリクエストを投げる
- 返ってきたユーザーリストを、表示中の箇所に反映させ、ユーザーキャッシュにも追加する
懸念点
- 問題点1.は多少改善するが、問題点2. はそのまま
案5. 案4において裏で走らせるリクエストの範囲を拡張
- 案4のページ表示時に裏で投げる、足りてないユーザーの取得リクエストを、キャッシュにないユーザーのみではなく、キャッシュにあるユーザーも見るようにする
- キャッシュにあるユーザーは即時表示するようにし、裏でユーザーキャッシュ更新用のリクエストを送る。その後レスポンスが返ってきたら表示に反映させ、ブラウザキャッシュを更新する。
個人的見解(yusuketk)
- 即時表示のためにはキャッシュは必須
- その解決案であるDB内キャッシュは、ユーザー情報更新時の負荷が重そう（足跡ユーザーやrevisionオーサーは膨大な数になりそう）なのであまり乗れない
- キャッシュなしで毎回populateするのも足跡ユーザーやrevisionオーサーなど考えると負荷が重くなりそう。だし、毎度それを行うという点がとてもよくない。
- 結論、ユーザーキャッシュは残しつつ最新の状態をある最短で反映させられる案5が良さそう