分散システムのテストを自動化する - Blog by Sadayuki Furuhashi
複数のプロセスが相互に連携して動くシステムのテストを自動化したい。 普通に書くとプロセスを起動したあと終了するまで待ってしまうので、複数のプロセスを同時に起動できなくて困ります。&を付けてバックグラウンドで起動させると、後で終了させたとき、まず ps aux | grepしてPIDを調べて、シグナルを飛ばして、しばらくポーリングして本当に終了するまで待つ、なんてことになって面倒です。 それから起動してからしばらくは初期化処理が走っているので、標準出力に「started」と表示されるまで待ちたかったりします。 そのあたりをうまく扱うためのライブラリを書いてみました。↓こんな感じで自動化できます。 #!/usr/bin/env ruby require 'chukan' include Chukan srv = spawn("server -arg1 -arg2") # 'server' コマ
MessagePack 0.3.0 リリース！ - Blog by Sadayuki Furuhashi
バイナリシリアライズ形式MessagePackのバージョン0.3.0をリリースしました。C API が大幅に充実、ストリームデシリアライザとメモリゾーンの効率化など。 MessagePackのプロジェクトページができました：http://msgpack.sourceforge.jp/ シリアライズフォーマットには完全な互換性があります。 APIはソースコードレベルではほぼ互換性がありますが、バイナリレベルでは互換性はありません。ライブラリは0.2.2と共存できますが、新しいAPIを利用するには再コンパイルが必要です。 ドキュメント整備 C APIの追加 メモリゾーンの機能強化 C/C++のストリームデシリアライザの効率化 シンプルなバッファの実装を標準添付 Ruby API で MessagePack.unpack_limit を追加 gemパッケージがシンプルに C APIの追加 オマケ
Ruby Rev + MessagePack による分散プログラム - Blog by Sadayuki Furuhashi
ネットワークプログラミングで面倒なのが、通信相手にバイト列しか送れないためプロトコルをシリアライズ方法から考えないといけないかったり、複数のクライアントに対応しようとするとスレッドやらイベント駆動やらを考えないといけないところで、なかなか本質的なロジックの実装に手を付けられずもどかしくなります。 そのあたりの面倒な部分をまとめて良きに計らってくれるRPCライブラリを作っておくと良さそうです。 とはいえ、RPCレイヤーはネットワークプログラミングの中でも速度と信頼性に大きく影響する部分でもあります。実装を丸々隠蔽されてしまうと、後になってカスタマイズできずに困ったことになるかもしれません。 最初のプロトタイピングとして簡単に使えるが、カスタマイズも効くような柔軟性が欲しいところです。 そこでRubyの高速なイベント駆動IOライブラリであるRevと、バイナリベースのシリアライズ形式であるMes
マルチコア時代の高並列性IOアーキテクチャ Wavy - Blog by Sadayuki Furuhashi
シングルスレッドではもう遅い。 以前にマルチコア時代の高速サーバーの実装で、「ネットワークIOはマルチスレッドで動かすが、その他の部分はシングルスレッドで動かす」というIOアーキテクチャの実装（mp::iothreads）を紹介しました。iothreadsはロジック部分をシングルスレッドで書けるため実装の手間を抑えることができ、ネットワークIOがボトルネックになるプログラムには特に適していると思われます。 しかし実際にiothreadsを使ってプログラムを書いてみると、非常に負荷が高い状況でシングルスレッドの部分の処理速度がボトルネックになってしまうことがありました。 そこでマルチコアCPUの性能を引き出すために、徹頭徹尾マルチスレッドで動かすIOアーキテクチャを実装してみました。 1つのスレッドが、ある時はepoll_wait()し、ある時はread(2)を行い、ある時はイベントを処理す
P2P分散ストレージ「Cagra」 - Blog by Sadayuki Furuhashi
id:nyaxt氏との共同開発の分散ストレージ「Cagra」（かぐら）のアルファ版をリリースしました。 cagra α3リリース cagra テクニカルデモ α２リリース 分散ストレージエンジンテクニカルデモ α版リリース cagraのα版試してみたよ - takumalog Cagraは以下のような特徴を持った（目指した）P2P分散ストレージです。 Zeroconf マルチマスタでレプリケーションするWrite 高速な分散Read オプションで高速な非同期Write インターネットレベルよりもLANレベルのマシン台数に特化 巨大データサポート 高速イベント駆動システムコール＋軽量スレッド 超アジャ〜イルな開発体制 まだα版で全部が実装されているわけではないですが、とりあえず動きます。 Zeroconf UDPマルチキャストでノードを自動的に発見するので、一切設定ファイルを書かずに動作せる
memcachedバイナリプロトコルは同期プロトコルを禁止するべき - Blog by Sadayuki Furuhashi
現状のmemcachedのバイナリプロトコルのクライアント（=libmemcached）は、リクエストの順番通りにレスポンスが返ってくることを期待しており、これはmemcachedバイナリプロトコルを「汎用的なkey-valueベースの分散ストレージのためのプロトコル」として考えると、ひどい実装である。 そのような実装は最適化の余地を大幅に制限してしまい、性能とスケーラビリティが悪化する。memcachedの仕様書は、そのようなクライアントの実装はバグであると明示するべきである。 現状のmemcachedクライアントの実装の問題点と、その解決策について述べる。 同期プロトコルと非同期プロトコル ネットワークプロトコルは以下の2つの種類に分けられる： 同期プロトコル リクエストの順番通りにレスポンスを返す（リクエストの順番とレスポンスの順番が同期している） 非同期プロトコル リクエストした順
2008-10-14
memstored は memcached のバイナリプロトコルをサポートしたハッシュストレージサーバーです。IO戦略ライブラリmpio の信頼性と性能をテストするために開発しました。 IOに mp::iothreads を使用し、バックエンドには Tokyo Cabinet の抽象データベースAPIを利用しているため、高速でスケーラビリティが高く、かつ柔軟性の高いアーキテクチャになっています。プログラムの大部分はライブラリによって実現されているため、プログラム全体の見通しが良く、行数で見ても非常に小さく収まっています。 SVN (memstored): http://svn.coderepos.org/share/lang/c/memstored/trunk SVN (mpio): http://svn.coderepos.org/share/lang/c/mpio/trunk パッケー
バイナリシリアライズ形式「MessagePack」 - Blog by Sadayuki Furuhashi
Googleが公開したバイナリエンコード手法であるProtocol Buffersは、クライアントとサーバーの両方でシリアライズ形式を取り決めておき（IDL）、双方がそれに従ってデータをやりとりするようにします。 この方法では高速なデータのやりとりができる反面、IDLを書かなければならない、仕様を変えるたびにIDLを書き直さなければならない（あらかじめしっかりとIDLを設計しておかないとプログラミングを始められない）という面倒さがあります。 ※追記：Protocol BuffersのデシリアライザはIDLに記述されていないデータが来ても無視するので（Updating A Message Type - Protocol Buffers Language Guide）、仕様を拡張していっても問題ないようです。 一方JSONやYAMLなどのシリアライズ形式では、何も考えずにシリアライズしたデータ
Protocol Buffersは遅い - Blog by Sadayuki Furuhashi
Google の Protocol Buffers は、同技術と競合するバイナリシリアライズ形式である MessagePack と比べて、場合によっては 19倍 以上遅く、シリアライズ後のデータサイズは 7倍 以上になることがあります。平均的に見ると MessagePack の方が高速であり、高い性能が必要とされるなら Protocol Buffers より MessagePack を選択するべきです。 …とはいえどちらも非常に高速なので、実際にはそのAPIの違いで選んだ方が良い。Protocol Buffers と MessagePack は重視している点が異なり、使い勝手は大きく異なる。 Protocol Buffers とは何か Protocol BuffersはGoogleが開発したバイナリエンコード手法で、以下のような要素が提供されます： データフォーマットを記述するための言語（
Key Value Store勉強会に行ってきました by kumofsのひと - Blog by Sadayuki Furuhashi
※分散Key-Valueストア「kumofs」を公開しました！ 先日開催されたKey Value Store勉強会に行ってきました。私の発表資料は↓ここからダウンロードできます。 kvs-kumofs.pdf 合わせて読むと理解が深まるかもしれない： スマートな分散で快適キャッシュライフ - mixi Engineer's Blog：Consistent Hashについて バイナリシリアライズ形式「MessagePack」：kumofsのプロトコル。高速なストリームバッファとストリームデシリアライザの実装も含まれています。 Protocol Buffersは遅い：MessagePackのベンチマークとProtocol Buffersとの比較。タイトルは釣り。 memstored：IOアーキテクチャのプロトタイピング マルチコア時代の高並列性IOアーキテクチャ Wavy memcached
開発環境としてのMac OS X Leopard - Blog by Sadayuki Furuhashi
なかなかrootにならせてくれない、ハードウェアを選ばせてくれない、設定ファイルをviでいじらせてくれないなど、不自由なUNIX : Mac OS Xですが、それ故の自由が何物にも代え難い今日この頃。Leopardになってcron+pdumpfsの仕事まで持って行かれてしまいました。 前回のTiger版カスタマイズメモに引き続いて、Mac OS Xのカスタマイズを書いておこうと思います。 Terminal.app タブ機能が実装されたりssh-agentがKeychainと統合されたりと、Leopardで驚異的なアップデートが行われたターミナル周りですが、まだまだ改善できる余地があります。問題は以下の3点。 HomeキーとEndキーが使えない 色が見にくい ショートカットキーが使いにくい まずHomeキーやEndキーですが、これは環境設定で変更できます。Terminal.appの環境設定の
古橋貞之の日記 - 開発環境としてのMac OS Xカスタマイズ
Mac OS Xを使っていないプログラマは、時間の80％を無駄にしている、かどうかは知りませんが、堅いGUIとUNIX系のコマンドラインツールを使えるMac OS Xは、開発環境として使いやすいことは確か。 が、デフォルトのままでは、Terminal.appで日本語が表示できないとか、lsやfindがGNU系じゃなくてBSD系だとか、要するにOSだってカスタマイズしてなんぼというわけであります。 というわけで、私のMac OS Xのカスタマイズをこのあたりに書いておきます。 ※2008/2/3追記: Leopard版書きました > 開発環境としてのMac OS X Leopard Terminal.app Mac OS Xにはデフォルトで「ターミナル」（/Applications/Utilities/Terminal.app）が付いてきますが、これがデフォルトではまったくイケてない。主要な
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
