Day 17: smart-buffer
これは fukamachi products advent calendar 2016 の17日目の記事です。
今日はsmart-bufferについて話します。裏側で使っているライブラリなのでたぶん知らない人がほとんどかと思うので紹介です。
Wooの成功
15日目に話したWooは想像以上に受け入れられ、すぐに実際に使ってみようという人が多く見られました。そしていくつか質問も飛んできます。
よくあった質問がこれでした。「ファイルアップロードしたときにファイルが全部メモリに載ってるよね？大きいファイルアップロードしたらやばくない？」
twitter.com@nitro_idiot For woo/http-body/fast-http, how are large files per multipart/form-data handled? Are they stored on disk or in memory?
— NIL (@Shinmera) 2015年7月1日
大きなリクエストの保持方法
もちろん、全部メモリに載せてたら問題です。Wooではこの問題に対してスマートな方法で対処しています。
リクエスト本文を読み込んでいき、サイズが小さいうちはインメモリバッファにロードします。もしサイズがしきい値を超えたらバッファの内容をファイルに書き込み、ファイルバッファに切り替えます。
つまり、小さいリクエストのときはインメモリで高速に処理し、大きいリクエストはファイルに書き出してメモリ使用を抑えます。
twitter.com@Shinmera Keeps them on memory first and dumps them to disk when their size exceeds the limit. https://t.co/4da7ZQkWwv
— fukamachi (@nitro_idiot) 2015年7月1日
元々fast-httpのmultipartパーサーの機能だったのですが、これは汎用的に使えるな、と思ってのちに別ライブラリにしました。それが「smart-buffer」です。
smart-bufferのアイデア
このアイデアは僕のオリジナルではありません。
Pythonにmultipartというmultipart/form-dataのパーサーライブラリがあります。これが全く同じ仕組みで動作し、小さいファイルアップロードにはメモリで、大きいファイルアップロードにはディスクで対応しています。
おわりに
smart-bufferはGitHubで公開されており、Starは7です。使っているライブラリはfast-httpとWooだけですね。
明日のアドベントカレンダーは18日目のtrivial-signalについてです。お楽しみに。
