grpcをさらっと触ってみた。僕の個人的な結論から言うと、小規模なシステムにはいれるメリットあんまりないけど、複数チームでわりとバラバラに開発をしてるけど同じRPCを叩く必要があり、なおかつそれなりのトラフィックがあるなら有効そう。
他の言語の事は知らん。とりあえずGoでさわる。github.com/grpc/grpc-commonをチェックアウトして、サーバーとクライアントを起動する。ドキュメント読んでるとProtocol Buffersの話とかでてくるけど、動かしたいだけなら全部忘れてよし。
これだけだと一回RPCが走るだけでつまらないので、client側を変えて100 goroutineでぼちぼちたっぷりのコールをするようにする変更した部分はこんな感じ。ローカルホストにサーバーもクライアントもある状態なので正直正しい計測ではない事はまず言っておく。その前提で ざっくり10000 jobs/sec。HTTP2のオーバーヘッドを含めてだいたいそんなものなのでまぁ悪くないな、って感じ。
と、ツイートしたら"net/rpcと比べてどう？"って聞かれたのでほぼ同じプログラムをnet/rpcで作ったところ、約25K jobs/secいけた。 というわけで生スピードでは負けてしまったが、プロトコルの複雑さの差分と、goのhttp2がついこの間作られたばかりであまり最適化されていない、というのがほとんどの原因だと正直思ってる。
この辺りの厳密な値はちゃんとサーバー立てて検証すべきだし、他の言語でも試すべきなので本当に雑談程度の認識にしておいてください。
それより、やはり方法論としてProtocol Buffersでプロトコルを定義してそれを複数言語用に自動生成できるのが強みかなーと思ってる。JSON Schema的な。あっちの大陸とこっちの大陸で作業してるチームがサーバー・クライアントのコードのひな形を簡単に生成して作業を始められるのは強いのではないだろうか。このコード生成をgoから試すにはgithub.com/google/protobufを入れた上でgithub.com/golang/protobuf/protoc-gen-go を入れる必要があるので注意。
以上、さわってみたエントリでした。
他の言語の事は知らん。とりあえずGoでさわる。github.com/grpc/grpc-commonをチェックアウトして、サーバーとクライアントを起動する。ドキュメント読んでるとProtocol Buffersの話とかでてくるけど、動かしたいだけなら全部忘れてよし。
$ cd go/greeter_server $ go run main.go
$ cd go/greeter_client $ go run main.go
これだけだと一回RPCが走るだけでつまらないので、client側を変えて100 goroutineでぼちぼちたっぷりのコールをするようにする変更した部分はこんな感じ。ローカルホストにサーバーもクライアントもある状態なので正直正しい計測ではない事はまず言っておく。その前提で ざっくり10000 jobs/sec。HTTP2のオーバーヘッドを含めてだいたいそんなものなのでまぁ悪くないな、って感じ。
と、ツイートしたら"net/rpcと比べてどう？"って聞かれたのでほぼ同じプログラムをnet/rpcで作ったところ、約25K jobs/secいけた。 というわけで生スピードでは負けてしまったが、プロトコルの複雑さの差分と、goのhttp2がついこの間作られたばかりであまり最適化されていない、というのがほとんどの原因だと正直思ってる。
この辺りの厳密な値はちゃんとサーバー立てて検証すべきだし、他の言語でも試すべきなので本当に雑談程度の認識にしておいてください。
それより、やはり方法論としてProtocol Buffersでプロトコルを定義してそれを複数言語用に自動生成できるのが強みかなーと思ってる。JSON Schema的な。あっちの大陸とこっちの大陸で作業してるチームがサーバー・クライアントのコードのひな形を簡単に生成して作業を始められるのは強いのではないだろうか。このコード生成をgoから試すにはgithub.com/google/protobufを入れた上でgithub.com/golang/protobuf/protoc-gen-go を入れる必要があるので注意。
以上、さわってみたエントリでした。
