kumofsに10MBのvalueを入れるとどうなるか実験してみた - sdyuki-devel
kumofsは、本来小さいサイズのvalueを大量に入れることを想定した分散KVSで、高解像度の画像など、サイズの大きいvalueを入れることは想定されていない。と言うかテストされていない。 でも、実は入れてみたら案外うまく動くんじゃないか？というわけで試してみた。 結論 データ総量30GB、物理ホスト１台で試した限りでは、実は問題は無さそう 物理ホスト１台というのが不十分なので微妙… ノードを追加したり復旧したりするとき、数時間の間、速度が半分くらいに劣化する データ量1TB、サーバ4台の構成で、2時間くらいかかる推定 データの再配置がタイムアウトしてしまう可能性があるが確認できていない。３台以上の構成で追試する必要あり 速度は、サーバ１台につき、Get 6.7 req/sec、Set 3.8 req/sec くらい ほぼ線形にスケールアウトすると仮定すれば、４台投入すれば Get 26
非同期プロトコルのクライアント - sdyuki-devel
非同期プロトコルとは、サーバーから返ってくる応答が、必ずしも要求した順番通りに返ってこないプロトコル（ソース無し。オレオレ定義）。 順不同で返ってくる応答と要求を対応づけるのはクライアントの仕事で、典型的には要求の中にシーケンス番号を入れておき、サーバーは要求と同じシーケンス番号を応答の中にも含める。 例：MessagePack-RPC 非同期プロトコルの特徴： イベント駆動型のサーバーの場合、サーバーの実装が簡単になる 同期プロトコルだと順番を揃えてから返さないといけない。サーバーの実装が（要求１つに対してスレッドを割り当てて処理するのではなく）ソケット１つに対してスレッドを割り当てて処理する方式だとあまり関係なくて、特に実装は簡単にならない。 処理が重い要求と軽い要求を続けて送っても、重い要求に詰まって後の応答が返ってこなくなることが無い 同期プロトコルだと、応答を送り返すにはその前の
ネットワークプログラムのI/O戦略 - sdyuki-devel
図解求む。 以下「プロトコル処理」と「メッセージ処理」を分けて扱っているが、この差が顕著に出るのは全文検索エンジンや非同期ジョブサーバーなど、小さなメッセージで重い処理をするタイプ。ストリーム指向のプロトコルの場合は「プロトコル処理」を「ストリーム処理」に置き換えるといいかもしれない。 シングルスレッド･イベント駆動 コネクションN：スレッド１。epoll/kqueue/select を１つ使ってイベントループを作る。 マルチコアCPUでスケールしないので、サーバーでは今時このモデルは流行らない。 クライアントで非同期なメッセージングをやりたい場合はこのモデルを使える： サーバーにメッセージを送信 イベントハンドラを登録；このときイベントハンドラのポインタを取っておく イベントハンドラ->フラグ がONになるまでイベントループを回す イベントハンドラ->結果 を返す １コネクション１スレッ
memcachedのストレージにSSDを使うアイディア - sdyuki-devel
memcached Night in Tokyo #1によれば、mixiはmemcachedサーバーを135台使っているらしい。多い！ 話に依れば一番最初に足りなくなるのはメモリの容量（3GBほど割り当てられている）で、ネットワークやCPUはボトルネックになっていないらしい。 ではメモリの代わりにHDDを使うのはどうか。HDDのランダムアクセス時の遅延がかなり大きいので、影響が出るほど遅くなりそう。 そこでSSDを使うのはどうか。ランダムリードで700Mbpsくらい出るらしいので、スループットに関してはCPUの方が先に限界に来ると思う。遅延はどれくらいか良く分からないが、アプリケーション側でget_multiを使っていれば隠蔽できないか。 バイト単価はDRAMよりはずっと安い。 実装としては以下： 32GBくらいのSSD 2GBくらいのメモリ（多ければ多いほどキャッシュに載りやすいので、平
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
