タグ

ブックマーク / frsyuki.hatenablog.com (4)

  • 第3回MessagePackハッカソン開催報告 - Blog by Sadayuki Furuhashi

    4月3日、MessagePackハッカソン第3回を開催しました。 14人のユーザーと開発者が集まり、実際のユースケースを元にしながら多くの問題が解決(への方針が決定)しました。 リンク MessagePack-RPC Erlang(α版くらい) MessagePack for OCamlを公開しました RPCのバージョニングサポート 背景 ソフトウェアはバージョンアップを繰り返すものですが、分散型のアプリケーションでは、単一のシステムの中で新旧のバージョンが混在して運用されることがあります。昨今のスケーラブルな分散システムでは、システム全体を停止せずに部分的にプログラムをバージョンアップさせていく ローリングアップデート と呼ばれる手法が利用されており、このようなケースでも 新旧のバージョンが互換性を保ったまま相互に通信可能である必要があります。 Thrift では、関数の引数やstruc

    第3回MessagePackハッカソン開催報告 - Blog by Sadayuki Furuhashi
    ita-wasa
    ita-wasa 2011/04/06
    プロジェクト JIRA(チケット管理)とConfluence(WIki)を導入しました。 JIRAはチケットのネストができます。日付型が欲しい→Java版で日付型を実装 というように、言語をまたいだ共通の提案→各言語の実装 という要求にぴっ
  • MessagePack-RPC for C++ テクニカルプレビュー - Blog by Sadayuki Furuhashi

    バイナリシリアライズ形式 MessagePack をプロトコルに利用したRPCライブラリ MessagePack-RPC の、C++版を開発しています。 以前に MessagePack-RPC for Ruby について 54行で実装する分散KVSや140行で作る分散リアルタイム検索エンジンを紹介しましたが、そのC++版です。 大まかな設計はRuby版と同じで、Ruby版と同じような使い勝手で利用できます。 しかしRuby版とは異なり、C++版では完全にマルチスレッドに対応しています。具体的には、マルチコア時代の高並列性IOアーキテクチャ Wavy を利用しています: 複数のスレッドでイベントループを共有しており、マルチスレッドでイベントハンドラを次々に処理していきます。 単純なイベント駆動I/Oと比べると、並列性が高いという利点があります。イベントハンドラの中で処理が多少ブロックしても、

    MessagePack-RPC for C++ テクニカルプレビュー - Blog by Sadayuki Furuhashi
    ita-wasa
    ita-wasa 2009/12/25
    大まかな設計はRuby版と同じで、Ruby版と同じような使い勝手で利用できます。 しかしRuby版とは異なり、C++版では完全にマルチスレッドに対応しています。具体的には、マルチコア時代の高並列性IOアーキテクチャ Wavy を利用
  • 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

    Key Value Store勉強会に行ってきました by kumofsのひと - Blog by Sadayuki Furuhashi
    ita-wasa
    ita-wasa 2009/02/25
    個人的に予想しているのはEthernet+ソフトウェアTCP/IPに代わる超低遅延ネットワーク。CPUやSSDの性能向上が頭打ちになる一方で、通信のオーバーヘッドが極端に低下することによって分散システムの設計がマルチスレッドプログラミング並の常識になり、スケールアウトすることで処理性能が飛躍的に向上する。その結果分散ストレージに求められる性能が増大する、とか! キーワードは10GbE、TOE、PCI-Express External Cabling、RDMA、SDPなど。
  • マルチコア時代の高並列性IOアーキテクチャ Wavy - Blog by Sadayuki Furuhashi

    シングルスレッドではもう遅い。 以前にマルチコア時代の高速サーバーの実装で、「ネットワークIOはマルチスレッドで動かすが、その他の部分はシングルスレッドで動かす」というIOアーキテクチャの実装(mp::iothreads)を紹介しました。iothreadsはロジック部分をシングルスレッドで書けるため実装の手間を抑えることができ、ネットワークIOがボトルネックになるプログラムには特に適していると思われます。 しかし実際にiothreadsを使ってプログラムを書いてみると、非常に負荷が高い状況でシングルスレッドの部分の処理速度がボトルネックになってしまうことがありました。 そこでマルチコアCPUの性能を引き出すために、徹頭徹尾マルチスレッドで動かすIOアーキテクチャを実装してみました。 1つのスレッドが、ある時はepoll_wait()し、ある時はread(2)を行い、ある時はイベントを処理す

    マルチコア時代の高並列性IOアーキテクチャ Wavy - Blog by Sadayuki Furuhashi
    ita-wasa
    ita-wasa 2009/02/02
    ここではepollにファイルディスクリプタを登録するときに、EPOLLONESHOTフラグを設定しているところがポイントです。読み込み可能なファイルディスクリプタが取り出されると、そのファイルディスクリプタは再度有効化されるまでepoll_wait()で報告されません。このためread(2)がEAGAINになるまで完了していなくても、他のスレッドがすぐにepoll_wait()を実行することができます。 また、取り出されたファイルディスクリプタを再度有効化する操作(epoll_ctl()でEPOLL_CTL_MODを指定)は、スレッドセーフであるようです。つまりread(2)がEAGAINになったら、ロックを取得せずに再有効化する操作を行うことができます(図中の「reactivate」)。
  • 1