BLOG::broomie.net: 多重化してThriftを使ってみた
ここまでの流れ Thriftの調査の続きです。前回のエントリー(Thriftのスピードが改善しました)では、Thriftのperlクライアントが遅いのはNagleアルゴリズムが原因ではないかという仮説をたて、そしてNagleアルゴリズムをオフにした状態で速度が向上したことを書きました。 それに対し、tokuhiromさんにより投稿されたエントリー(ThriftはThrift::BufferedTransport をつかいわすれると 147 倍遅くなってつかいものにならない)では、send(2)のバッファリングをしていないことが原因で、Thriftが吐き出すデフォルトのperlクライアントのスケルトンでは使われていない、 Thrift::BufferedTransport を使うことによってsend(2)がバッファリングされて、高速になることを示してくれました。加えてkazuhookuさんの
BLOG::broomie.net: Thriftのスピードが改善しました
先週末はThriftのスピード問題にはまり、ガンダム戦記にはまり、ほとんど外に出られませんでした。前回のエントリー(Thriftのスピードについて)の続きとなります。 やっぱりperlのクライアントライブラリに問題がありそう？ 多くの有識者の方にアドバイスをいただき感無量でございます。前回のエントリーでは、perlライブラリ、pythonライブラリでThriftが異常なほどに遅いんじゃないか？といった内容でございました。当方のバグではないかと、おそるおそる前回のエントリーをポストしたのですが、tokuhiromさんがこの現象に関して調査と考察の結果を示してくれました(ThriftのPerl Clientが遅すぎる件について)。 クライアントが Pure Perl で書かれており、かつ実装に適当さが感じられ、「速そうには、みえないな。。。」と感じました。 Facebook 内で実際に使用され
BLOG::broomie.net: Thriftのスピードについて
shunyaです．最近Crystal Keyのアルバムを聴いていてCrystal Keyが改めて良いと思いました．切なくて甘酸っぱいです． Thriftのパフォーマンスについて さて，前回のエントリー(Thriftが便利すぎる)では，僕が感じたThriftの便利さを熱弁する内容となっておりました．始めて使った感想としてはすごく便利！だったわけですが，実際に何かしらのサービスに導入するためにはThriftのパフォーマンスをチェックしなければなりません． で，今回は簡単なThriftのベンチをとってみることにしました．僕的に気になるのが，前回のエントリーでも書いたようにRESTととの違いです．つまりRESTではCGIを使ってHTTPで通信するので，比較的高速に処理できます．それに対して，Thriftでは独自に定義されたRPCで通信します．とても便利なのはいいのですが，この独自のプロトコルがどれ
Kansai.pm#10 での発表資料 (Thrift について) - naoyaのはてなダイアリー
今日は第10回 Kansai.pm でした。自分も 10 分だけ、Thrift について発表を行いました。資料を以下にアップロードしました。 http://bloghackers.net/~naoya/ppt/080810kansaipm.ppt (ppt) http://www.slideshare.net/naoya1977/about-thrift/ (Slide Share) Thrift については今月末発売の WEB+DB PRESS Vol.46 の連載記事でも解説を行っていますので、興味のある方はご一読いただければ幸いです。 今回の Kansai.pm、場所は弊社オフィスで開催でした。閉会後そのままピザを取って懇親会に。なぜか id:azurestone さんらと Linux セキュアOS についての話題で盛り上がっておもむろにカーネルのコードリーディングが始まったり、こち
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
