ポールが最近投稿したブログ記事「本番前のテストは効果的か？」について、さらに詳しく述べたいと思います。 ポールはCPU使用率やコードパスについて触れていましたが、多くのアプリケーションにはもう一つ、非常に重要な側面があります。それはネットワーク使用率です。多くのアプリケーションは、レイテンシが1ミリ秒未満、帯域幅が少なくとも100MbpsあるLAN環境でテストされます。しかし、実際にデプロイされると、帯域幅が狭く、レイテンシがはるかに高いWAN環境で利用されることになります。その結果、悲惨な事態を招く可能性があります。
LAN環境でのテストでは、ネットワーク関連のバグのほとんどは発見できますが、パケットの損失や予期せぬセグメンテーション（TCPはメッセージの境界を維持しません）に関連するバグについては、LAN環境では発見されにくい可能性があります。 また、高速なLAN環境では、低速なWAN環境に比べて、設計が最適でないことに気づきにくい傾向があります。したがって、ネットワークベースのアプリケーションは、想定される最悪のネットワーク環境（低帯域幅、高遅延）下でテストすることが非常に重要であり、パケット損失率も忘れずに考慮する必要があります。
これを行うには2つの方法があります。
まず、実際の環境を使用する方法です。サーバー（またはクライアント）をネットワーク上のホストに配置し、動作を確認します。この方法の利点は、実際のインフラストラクチャを利用できることです。一方、欠点は環境を制御できないことであり、これは問題を再現したり、バグ修正をテストしたりする際に極めて重要な要素となります。
2つ目は、WANシミュレータを使用することです。ハードウェア型やソフトウェア型、商用やオープンソース（無料）のシミュレータが存在します。ここでの利点は、遅延やパケット損失率、その他のネットワークパラメータを完全に制御できること、そして他のグループに協力を依頼する必要がない（つまり、他人のシステムに自分のソフトウェアをインストールする必要がない）ことです。 デメリットはコストと習得の難易度です。たとえ無料のソフトウェアを使用する場合でも、それを実行するためのシステム（通常はUnix系OS）を用意し、その使い方を習得する必要があります。数年前、私はDummynetに関するチュートリアルを書きました。当時は、利用可能な数少ない無料シミュレータの一つでした。現在ではさらに多くの選択肢があります。「wan simulator」とGoogleで検索してみてください。
パフォーマンスやアプリケーションの障害に関するこれまでの経験から、この種のテストは、バグによる本番環境のダウンタイムを削減し、アプリケーションとユーザーの双方のパフォーマンスを向上させることで、その費用以上の効果をもたらすものと確信しています。