みんカラにアクセスすると。
同じ車種の新人さんが羅列され、「お友達どうよ？」的なブツが表示されます。
普段読み流すのですが・・・。
「匠 ＦＡＣＴＯＲＹ」さんが今日、表示されとりました。
このヒト、先日のziro!さんBlogでも出てきましたが、オイラの短いみんカラ歴の中でも、歴史が古いお友達です。
ここの欄に、「お友達的な知り合い」が出てきたことは、過去に１回しかありません。
「ひろ兄５５５」さん、一度辞めて再登録した際、ですね。
が、匠さんそんなことしたのかな？、同じ名前の別人なのかな？、とアクセスしたら。
まず、愛車のイイネが「１０」、これご本人ですよね？。
そして止めは、「既にお友達です」、いやもう完全にご本人ですよね？。
何でだろ、バグ？。
・・・とまぁ、ここで終わりにしてもいいのですが。
「バグでは無くて仕様変更」だという前提で、掘り下げてみましょうか。
オイラが掘り下げたり思考実験すると「ネガティブ方向」なお話に飛ぶ事が多く、結構問題を発生させとりますが、、、オイラは「喧嘩売る気」はありません。
が！、特にクルマに関する話題はケアフルに扱い、安易に否定方向に持っていかないよう、注意を払うようにします、今まで関係悪くしてしまった方、ゴメンナサイ、、、。
ですがまぁ、今回の「被害者」はコイツだけだと思うので、まぁ大丈夫でしょう！。
＊ゴミ拾いをするミント氏。
オイラはWeb屋を趣味でやってますが、完全独学の上に言語とかDBとかよーわからんので、まぁヨタ話ってことで。
多分ですが、元々この機能：
・新規に登録されたユーザーをクルマ別に分けリスト化（簡易プロフィールコミで）
・ユーザーログイン毎に、友達有無を確認し、差分を取る
・そこからランダムに数人（携帯は１人）選び、表示
リストの作りざまは：
・上記リストは「５０人」とか制限があり、１日１回くらい切り詰める
・切り詰め後から新規登録者は追記でリスト追加
って実装かな？と思っています。
今回匠さんが引っ掛かったのは、このルールが：
・新規に登録「、若しくは更新された」ユーザーをクルマ別に分けｒｙ ←「」内ルール追記
・ユーザーログイン毎に、友達有無を確認する機能削除
あたりかな、と思ってみたり。
気持ちは分かります。
１番目、「更新されたユーザー」は、まぁアクティブ度が高いしお友達候補としてはOKかと。
問題は２番目、「友達有無の確認削除」。
これ多分、サーバ負荷増大に対する措置、かと。
ログイン毎にランダムで何やらする、ての、HTTPを使う以上、リストが大きくなってくると大変です。
＊HTTPは実装上、「待ち」が許されません、テキストの場合、遅くても数秒以内に結果を返す必要があります（裏ワザはありますが）。
mixiも当初、「お友達」「加入コミュニティ」をログイン毎？アクセス毎？にランダム生成してましたが、最近はしてません。
ここでオイラならどうするか、考えてみました。
まず多分、バッチ用サーバを立てます。
前処理として、「車種リスト」を共有します。
んで、フロント側からは、「新規、更新登録者」を離散的に貰います。
バッチサーバ側で、車種別に分類し、「候補リスト」を作製します。
候補リストは、バッチサーバのcronで適宜処理し、あまりデカくならないようにします。
んで、ユーザアクセス時。
「ユーザがアクセスしたよ！」、て情報を、フロント側から貰います。
もしバッチサーバ内に「ユーザに対する候補リストとお友達の差分キャッシュ」が無い場合、候補リストをそのまま、もしくはランダムに数件返します。
バッチサーバには常に「ユーザに対する候補リストとお友達の差分キャッシュ」をアクセスされたユーザに対して作り続けます。
キャッシュは、そうですね、賞味期限「２日」とかに設定するかな？。
もし、キャッシュが新しい場合は、キャッシュをフロントに返します。
もし、キャッシュが古い場合は、古いキャッシュを渡しつつキャッシュ生成待ち行列に突っこみます。
もし、キャッシュが無い場合は、上記対応後やっぱり待ち行列へ。
この実装での問題点は、
・ユーザの「お友達リスト」をDBやディスクサーバから引き取る際の負荷
・そもそもの演算負荷
・フロントからの問い合わせに対するネットワーク負荷（ソケット）
・導入時負荷（キャッシュ０だと大変マズい！）
かなぁ・・・。
解決案は、こんな感じかな。
・ユーザの「お友達リスト」をDBやディスクサーバから引き取る際の負荷
→キャッシュ更新頻度の低減、キャッシュ更新自体を午前４時とかにまとめて仕掛ける
「待ち行列」を処理する時間の制限、ですね
→どーせフロント側は「お友達リスト」をDB等から同時に取得している筈なので、アクセス時にそれ貰っちゃう
・そもそもの演算負荷
→キャッシュサーバを更に分離し、演算用サーバをパラで投入
・フロントからの問い合わせに対するネットワーク負荷（ソケット）
→フロントからのネットワーク分離、HTTPアクセスの場合当然Connection:close (キープアライブOFF)
フロント側にもキャッシュコピーを置き、頻繁にアクセスするユーザのリクエストを低減させる
・導入時負荷（キャッシュ０だと大変マズい！）
→スイッチ時は例えば１週間とか掛けて、じんわりキャッシュを溜めてから投入
投入時はキャッシュ更新頻度に時間的Delayを掛け、ちょっとづつキャッシュ更新
まー、こんな感じかなぁ・・・。
若かりし頃は、こんな案件別にサーバ立てたりしてましたが、今は１つにまとめています、ウチの場合は。
ま、でも負荷が読めないんなら流行りの仮想サーバとか立てて実験、かなぁ、、、でも仮想サーバの場合、「ネットワーク、ディスクのボトルネック」が測りづらいのが気になるな。
ま、こんな感じ。
プリウスさんとは全く関係無い話題、でした。
そしてこの話題「みんカラ開発（ミント君）」になった積りで読んでみて、感想コメ頂けると嬉しいです。
・・・やっぱり、ムカつく？。
さて。
やっとです。
みんカラにアクセスすると。
今日のBlogは、、、。
さて今日は。
