バージョンを変更することができます。運営側としては、利用するゲームアプリに気兼ねすること無く、新しいバージョンのサーバアプリをデプロイすることができます。裏側の裏話ここまでで説明した構成は、実装前の設計段階で固まっていて、大きな変更はありませんでした。細かいところでは当然ながら初期の設計どおりではまずい箇所がいくつか出てきました。負荷テストを実施してみると思わぬところがボトルネックになっていることが分かりました。ワードチェック、そして参加チャンネルの管理程度に留めたいと考えていました。ネットワーク上にユーザを登録する構成を考えていました。管理する接続の数は、1クライアントにつき2つの接続になります。管理する接続の数が増えるとそれだけリソースを消費するため、さばけるクライアントの上限が低くなってしまいます。接続を作るという設計では、目標とする性能を実現できませんでした。1つで済ませることにしました。上にも実装する必要に迫られることになりました。リソースを消費することになります。応答性はクライアントのユーザビリティに直結します。チューニングには特に時間を費やしました。実行速度が期待できます。導入によりパフォーマンス向上の効果は一定ありましたが、それでもまだ目標とするパフォーマンスには到達しませんでした。プロファイリングを取得して、ボトルネックを解析し、対策を施しました。マルチタスク処理部分であることが分かりました。処理の高速化が肝になりました。デフォルト引数群に、デフォルト値以外の値が渡されない場合だけです。クラスのオブジェクトをキャッシュしておくようにしました。実装が使われる場合があります(※)。