LadyBUG のメモメモ このページをアンテナに追加 RSSフィード

2007.03.01Tips: room.observe は迅速に このエントリーを含むブックマーク このエントリーのブックマークコメント

room.observe はできるだけ迅速に再接続を行ったほうがよいそうです。

room.observe のレスポンスには、大きな要素として、counter と messages, occupants が含まれる。通常、手続き型に処理を記述すると、

void OnObserveEvent(response, currentCounter)
{
  if (response.messages)
  {
    // response.messages を処理する (*)
  }

  if (respnse.occupants)
  {
    // response.occupants を処理する (*)
  }

  // response.counter を使用して新しい room.observe を呼び出す
  requestNewRoomObserve(response.counter);

という処理になりがちです。この処理順序に大きな問題があるわけではないですが、チャットルームが非常にホットな場合に少し Lingr サーバに負担をかけることが知られています。

特に、(*) を記述した2つの処理で複雑なことをしていればしているほど、この傾向が強くなります。

room.observe を呼び出すと、Chat Server Cluster に対してあたらしい notify の通知を待機します。この時、room.observe に与えた counter の値がなんらかの理由で古い場合、Chat Server Cluster は get のリクエストを実施し、Web Server Cluster から過去の発言を取り寄せるという処理が実施され、クライアントの counter の値を最新のものに更新しようとします。(参考 Lingr Backend Architecture)

さて、どのような場合に counter の値が古くなってしまい、get のリクエストが発生してしまうのか? その1つに、room.observe を呼び出して observe による notify の待機を行っていない状態で、新しいイベントが十分に発生してしまったというケースがあります。

  1. room.observe から新しいカウンタとイベントを手に入れる
  2. 受け取ったイベントを処理するのに手間取る
  3. 手間取っている間に別のイベントが発生
  4. 手に入れた新しいカウンタで room.observe を呼び出す
  5. get 処理が発生!
  6. 最初に戻る

というステップから、

  1. room.observe から新しいカウンタとイベントを手に入れる
  2. 手に入れた新しいカウンタで room.observe を呼び出す
  3. 受け取ったイベントを処理するのに手間取る
  4. イベントが発生
  5. 最初に戻る

というステップへと修正することが可能なら、修正したほうが Lingrサーバ側に負担がすくないらしいよ! ということです。

この修正は案外と面倒です。room.observe の要求を非同期で簡単に行う仕組みを備えている開発環境であれば、かなり簡単にすみます。そうでない場合、受け取った messages と occupants をキューに格納しておいて別スレッドで処理をするなどなど、いくつかの問題点が発生するでしょう。

可能な方は、ぜひ挑戦してみてください。