高スループット対応のネットワーク製品は実に大変

今日は一日、製品の検証・改良を行っていました。10Gbpsでリンクし、高価な負荷試験装置で呆れるほどの負荷をかけながら動きを観察し、性能・安定性を追い込んでいく作業です。

このレベルになると、ほんの少しの無駄な動きがかなり目に見えるくらいの影響になります。スループットグラフを見ていると、ちょっとでも無駄な処理が残っているだけで帯域にムラができ、負荷を増やすごとに性能が低下していくような感じになります。

大変なのは、その原因を突き止めることで、高負荷にならないと問題が目立たないため、デバッガで動きを追いながらという感じでは無理なことが多く、できるだけ狙いを定めてログを出しながら調べるくらいしか方法がありません。ログを出すこと自体も性能に影響しますし、ログ側の排他処理の影響で問題が再現しなくなることなどもよくあります。

回線事業者クラスのインターネット回線で使うような装置では、負荷試験装置と帯域的には同じくらいの負荷でも、パケットの内容のバラツキなどによりさらにプログラム側には負荷がかかることがほとんどです。そのため、負荷試験で「なんか変だけど・・・まあいいか」と手を抜くと、本番回線につないだ際にまず間違いなく問題が出ます。

昨年末からスレッド数を減らしてepollで多重化するバージョンに作り替えをしてきましたが、ようやく今日、ほぼ満足できるレベルの結果が出るようになりました。まだ負荷のパターンによっては性能に影響が出るケースもあるので、改善の余地はあるのですが、多スレッドバージョンに比べると格段の安定性・省メモリーで動き、性能も安定して上回る状態になりました。

最初のプロトタイプができてから既に2年以上試行錯誤を続けてきて、ようやくこれなら多くの回線事業者で使えるレベル（分散が必要なケースもありますが）になった感じで、ホッとしているところです。

他の製品のサポートなども対応しながら試行錯誤を繰り返してきて、そろそろ精神的に折れそうな状態でしたが、やっと明るい兆しも見えてきた感じです。そろそろ少しはリフレッシュしたいところですが、土曜日からバンコク出張ですし、少しでも休めるタイミングで心身ともにのんびりしないと・・・。