博士

ロボ子、今日のITニュースはライトコアレッシングについてじゃ。

ロボ子

ライトコアレッシング、ですか。初めて聞きました。

博士

ふむ。ライトコアレッシングはI/O最適化技術の一種で、複数の小さな書き込みをまとめて大きな書き込みとして基盤システムに送るものじゃ。

ロボ子

なるほど。Http/2では、複数のストリームからのフレームをバッチ処理して一度に送信できるんですね。

博士

そうじゃ！システムコール数が減って、負荷時に小さなTCPパケットを大量に送るのを防げるのがミソじゃ。

ロボ子

TCPといえば、Nagleのアルゴリズムというのもありましたね。これはライトコアレッシングとどう違うんですか？

博士

Nagleのアルゴリズムは、TCP/IPネットワークの効率を上げるためにパケット数を減らすものじゃ。でも、遅延ACKという別のアルゴリズムとの相性が悪いと、最大500ミリ秒も遅延することがあるんじゃ。

ロボ子

500ミリ秒は大きいですね。ライトコアレッシングは、その問題を解決できるんですか？

博士

nim-hyperxでの実装例を見てみよう。フレームをすぐに送信せずにバッファに追加して、バッファがいっぱいになるまで待つんじゃ。そして、いっぱいになったら一気に送信！

ロボ子

バッファサイズには制限があるんですね。最大サイズは64KB + ストリーム数 * 最大フレームサイズ、と。

博士

そうじゃ。この最適化で、2倍の高速化が実現したらしいぞ。さらに最適化を重ねると、5倍にもなったとか。

ロボ子

すごい！nim-hyperxは、単一インスタンスで約245Kリクエスト/秒、8インスタンスで+1Mリクエスト/秒を処理できるようになったんですね。

博士

syscallの数を減らすことや、大きなデータチャンクを送信してTCPパケットを有効活用することを意識していなかったのが、今回の発見だったようじゃな。

ロボ子

Nagleのアルゴリズムも良いけれど、アプリケーションコードでバッチ処理を行う価値がある場合もあるんですね。

博士

その通り！ライトコアレッシングは、ネットワークをより有効に活用し、socket.send呼び出しを減らすのに役立つバッチ処理技術じゃ。

ロボ子

勉強になりました！

博士

ところでロボ子、ライトコアレッシングって、なんだかお菓子の名前みたいじゃないか？

ロボ子

確かに。ライト（軽い）コア（核）レッシング（ドレッシング）…みたいな？

博士

うむ！今度、ライトコアレッシング味のクッキーでも作ってみるかの！

ロボ子

どんな味になるのか、想像もできません…！