ポール氏の最近のブログ「Is your pre-production testing effective?Paul氏はCPUの利用率とコードパスをカバーしていますが、多くのアプリケーションでは、ネットワークの利用率というもう一つの非常に重要な側面があります。多くのアプリケーションは、待ち時間がミリ秒以下の範囲で、帯域幅が少なくとも 100 mbps の LAN 環境でテストされます。そして、それらのアプリケーションは、より小さい帯域幅とはるかに高いレイテンシを持つWANで使用されるように配備されます。その結果、大惨事になる可能性があります。
LAN 環境でのテストではほとんどのネットワーク関連のバグを発見することができますが、パケットのドロップや予期せぬセグメンテーション (TCP はメッセージの境界を維持しません) に関連したバグがあるかもしれません。また、高速なLAN環境では、低速なWAN環境では、最適な設計ではないことに気づく可能性がはるかに低くなります。したがって、最悪のネットワーク環境、低帯域幅、高遅延、パケットロス率などを想定して、ネットワークベースのアプリケーションをテストすることが非常に重要です。
これには2つの方法があります。
1つ目は、実際の環境を利用することです。ネットワーク上のホストにサーバ(またはクライアント)を置いて、それがどのように動作するかを見てみましょう。これには実際のインフラを使うという利点があります。不利な点は、問題を複製したりバグフィックスをテストしたりする場合には、環境をコントロールできないことです。
2つ目はWANシミュレータを使うことです。ハードウェアとソフトウェアのみ、商用とオープンソース（フリー）シミュレータがあります。ここでの利点は、あなたがレイテンシ、パケットドロップ率や他のネットワークパラメータの総制御を持っていることであり、あなたは他のグループを（すなわち、他の誰かのシステム上であなたのソフトウェアを置く）関与する必要はありません。欠点はコストと学習曲線です。フリーソフトウェアを使ったとしても、それを実行するためのシステム(通常はUnixの何らかのフレーバー)を提供し、その使い方を学ばなければなりません。数年前、わたしはDummynetのチュートリアルを書きました。当時は数少ないフリーのシミュレータの一つでした。今ではもっとたくさんのシミュレータがあります。
パフォーマンスとアプリケーションの障害問題を見てきた私の経験に基づいて、この種のテストは、バグによる生産停止を減らし、アプリケーションとそのユーザーの両方のパフォーマンスを向上させることで、それ自体に見合うだけの代償を払うことができると信じています。