actix_web は Actor モデルを採用した Rust の web frameworkです。
「Actor モデルでwebリクエストを捌く」仕組みを雑に想像すると、
TCPリスナーがHTTPリクエストをメールボックスに貯め、それをワーカーであるActorが拾ってレスポンスを返す？
この仕組だと複数のActorで1つのメールボックスを共有する機構が必要になってきます。
しかし、Actorシステムを提供する actix にはこの機構はなさそうに見えます。
それに、恐らくこの仕組みでパフォーマンスを出すのは難しいでしょう。
そこで、actix_web がどのようにHTTPリクエストを捌いているのか、ソースコードを追ってみることにしました。
※ 読み間違え等ありましたらコメント頂けると大変嬉しいです… 🙏
Jupyter Notebook 便利ですよね！
REPL感覚で使えるけれど、REPLより使い勝手良いし、セルごとに何度もやり直しできるし、リンクを共有すればコードもさくっと共有できます。
Scala にも spark-notebook や Apache Zeppelin などの ノートブック形式Webアプリケーションがいくつかありますが、いつも使っている Jupyter Notebook で Scala を動かしたかったので、今回 Jupyter Notebook のカーネルに Scala を追加しました。
この記事を書いた経緯なのですが、「jupyter-scala」 の名称が変わっていたりインストールの仕方が変化していたため、一旦まとめた次第です。
※ この記事を書いているのは 2018.11.01であり、今後も変更の可能性は大いにあります。。。
Rust の Web Framework、 actix_web は TechEmpower のベンチマークでは、すごいパフォーマンスを示しています。
しかし、業務で使おうと思ったときに、本当のところどうなの？というのは気になるところです。
特に私の所属するアドテク界隈では、ミリ秒単位のパフォーマンス・チューニングが求められます。
実際、当初actix_webで要求レイテンシを満たせませんでした。
しかし、同僚の非常に有用なアドバイスにより打開することができたため、ブログにて公開しようと思った次第です。
パフォーマンスの測定及びチューニングは、下記のケースで行いました。
※ 実は上記以外のケースでもベンチマークを取っております。結果とソースコードはGithubにて公開しました。
https://github.com/x1-/actix_web_benchmark
結果だけ知りたい方はこちらをご覧になられた方が良いかもしれません。
2018.11.01 追記
actix_web は HTTPコネクションが正しく閉じない問題が未だ解決しておりません(TT)
Connection not closed correctly #439
昨日(10/31)、 @legokichi さんから TCP FIN が正しくされていないのでは？とご指摘が入っています。
前回の Rust を Bazel でビルドする〜前編〜 の続きです。
Bazel のインストールやかんたんなビルド操作については 前編 をご覧くださいませ。
ソースコードの完全版はGithubに公開しておりますので、合わせてご覧頂くとわかりやすいかもしれません。
https://github.com/x1-/rust_bazel_sandbox
そんなに需要がないだろうなあ、と思いつつも、ちょっと面白かったので記事にしました。
Rust で書いたソースコードを Google製ビルド・ツール Bazel を使ってビルドします。
Rust の場合、通常であれば迷わず Cargo でビルドしたいところです。
しかし、多言語を扱う monorepo スタイルの開発であったり、C/C++ソースも一緒にコンパイルしたい場合、複数言語のビルドを一貫して行える Bazel という選択肢がでてきます。
(tensorflow/rust を使うときもですかね)
参考: 大規模ビルドシステムにおけるRustの扱いに関する議論
(ここでも議論されています)
Bazel では、ビルドするためのルールを BUILD というファイルに記述します。
様々な言語向けのルールが既にたくさん用意されているので、BUILD にダウンロード設定を記述して使うことができます。
ありがたいことに Rust もありました。(なければ自作すれば良いのですが、、、)
これを使って、 Bazel で Rust をビルドしてみます。
ソースコードの完全版はGithubに公開しておりますので、合わせてご覧くださいませ。
https://github.com/x1-/rust_bazel_sandbox
GCPに限らず、Cloud のマネージド・サービスを使おうと思うと、そのクライアント・ライブラリが提供されているか言語を選択することが重要になってきます。
もちろん、クライアント・ライブラリが提供されていなくても、接続仕様が公開されていれば自力実装しても良いです。
が、普通に考えればサービスを提供するベンダーが提供しているものの方が信頼度が高そうなのは言うまでもありません。
Google の CloudサービスであるGCPのマネージド・サービスのクライアントですと、Go, Java, JavaScript(Node.js), Python, Ruby においてはクライアント・ライブラリが提供されています。
また、APIs のクライアント・ライブラリでは、上記にプラスして .NET, PHP, Objective-C, Dart などが提供されています。
想像通りですが、Rustなんて影も形もありません。
そこで敢えてRustでGCPマネージド・サービスに挑もうとするとすると茨の道に見えたのですが、やってみたら意外とあっさりできてしまったのでこのブログに書くことにしました。
2018年3月16日(金)に行われたScalaMatsuri2018トレーニングDAYでビッグデータについてお話させて頂きました。
ビッグデータで弱小卓球部を強くしよう！というふざけた内容です。
