It's like JSON. but fast and small. MessagePack is an efficient binary serialization format. It lets you exchange data among multiple languages like JSON. But it's faster and smaller. Small integers are encoded into a single byte, and typical short strings require only one extra byte in addition to the strings themselves. Next: MessagePack is supported by over 50 programming languages and environm
デブハゲ
でぶはげ めしくえ
「分散システムのためのメッセージ表現手法に関する研究」 - 筑波大学大学院を卒業しました - Blog by Sadayuki Furuhashi
このたび筑波大学大学院を卒業し、修士号を取得しました。卒業にあっては本当に多くの方々にご助力いただきました。この場を借りて御礼申し上げます。ありがとうございました。 現在は起業して、12月からアメリカに在住しています。新たな価値を生み出すべく "下から上まで" システムの設計と開発に携わっており、エキサイティングな毎日を送っています。 修論シーズンに日本にいなかったので、修士論文はメールで送って提出し、卒業式にも出席していないというありさまなので、本当に卒業できたのかどうか実感がないのですが、友人によれば「学位記はあった」らしいので、きっと大丈夫でしょう。（写真はカリフォルニア州マウンテンビューにて） さて、せっかく時間を割いて書いたので、修士論文を公開することにしました。 分散システムのためのメッセージ表現手法に関する研究と題して、バイナリ形式のシリアライズ形式である MessagePa
ここ数日、MessagePackがIETFにおける標準化に巻き込まれてザワザワしています。 何が起きているかというと、MessagePackプロジェクトとは関係が無い第三者がIETFで派生物の標準化を進めようとしています(binarypack、Informational RFCとして)。 binarypackは、自らをMessagePackの派生であるとしながらも、MessagePackとの後方互換性が無いものです。 MessagePack is in danger! binarypackのInternet-Draftを提出しているのは、coreと6lowpanのchairです。 Chairであるかどうかが議論そのものに与える影響はそこまで大きくないとも言えますが、少なくともIETFでの話の進め方に精通した人物であることは確かです。 ただ、今回のInternet-Draftは、その人物がC
Introducing the MessagePack - Blog by Sadayuki Furuhashi
高速なシリアライズライブラリ MessagePack の新しいWebサイトをオープンしました！ The MessagePack Project Ruby Inside でも取り上げられたようです： MessagePack: Efficient, Cross Language Binary Object Serialization 昨今、効率を重視したシリアライズライブラリが数多く登場しています。特に、大量の処理を行う大規模な基盤システム向けに開発されていることが多いようです。 少し探してみるだけでも、次のような事例が見つかります： BERT（githubで採用：Introducing BERT and BERT-RPC） Thrift（Facebookが開発：Thrift: Scalable Cross-Language Services Implementation） Avro（Hado
バイナリシリアライズ形式「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などのシリアライズ形式では、何も考えずにシリアライズしたデータ
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
ruby 2.0.0-p195 + fluentd v0.10.35 + msgpack v0.5.5 の組合せが素敵という話 - たごもりすメモ
fluentd v0.10.35 が出ましたね！ https://rubygems.org/gems/fluentd で、端的に申し上げまして fluentd をお使いの皆様は以下の組合せで使うのがおススメです。 Ruby 2.0.0-p195 Fluentd v0.10.35 MessagePack v0.5.5 なぜかというと以下のようなすばらしい利点があるからですね。 Ruby 2.0.0 でfluentdを走らせると大変高速 2.0.0 は each とかを回すときに非常に高速になるような改良が入っている 1.9.3 向けには funny-falcon patch として知られていたもの rvm を使ってビルドしていたrubyだと知らずに当たってるかも これが大量のメッセージに対してループが回りつづけるFluentdに超ハマる 手元計測で生の 1.9.3 の倍ちょっと高速 Ruby
Treasure Dataの基本データフォーマットであるMessagePackと、msgpack-javaでの最適化について紹介します。Read less
MessagePackフォーマット仕様のPull Request #209をマージし、MessagePackにTimestamp型を追加しました。 ※この記事の英語版は XXX にあります（翻訳中） Extension型の型コード -1 として定義されているため、後方互換性が維持されています。つまり、既にExtension型に対応しているデシリアライザであれば、Timestamp型を使用して作成されたデータを、Timestamp型に対応していない古いデシリアライズで読み出すことができます。 新しいTimestamp型には timestamp 32、timestamp 64、timestamp 96 の3つのフォーマットがあり、よく使う値をより少ないバイト数で保存できるようになっています。例えば、1970年〜2106年までの時刻で、秒までの精度しか持たない時刻であれば、合計6バイトで保存でき
phpのserializeを使うより高速でサイズもコンパクトに仕上げる「MessagePack」とPHP拡張:phpspot開発日誌
phpのserializeを使うより高速でサイズもコンパクトに仕上げる「MessagePack」とPHP拡張 2010年12月15日- The MessagePack Project phpのserializeを使うより高速でサイズもコンパクトに仕上げる「MessagePack」とPHP拡張。 結構前のエントリのご紹介なので知っている人も多いと思うのですがご紹介。 phpには serialize という関数があって、配列等の複雑なデータも文字列にして、ファイル等に保存し、後ほど unserialize 等で変数に戻せて便利なのですが、MessagePackとそのPHP拡張を使えば、より高速で、serialize後のデータも小さくできます。 MessagePack自体はkumofsの内部で使われていて、PHP以外にもc++, erlang, haskell, java, perl, pyth
MessagePackというオープンソースプロジェクトの現状と IETF による標準化について、それが果たして正しいのか、と困惑せざるをえない事態が起きているので、それについて簡単に書く。何が起きているのか知らない人々に少しでも知ってもらえたら嬉しい。 なお、自分はMessagePackのユーザであって開発者ではない。MessagePackを使ったコードを書いて動かしているが、MessagePackそのもののデータフォーマットについて詳細まで知っているわけではないし、MessagePackの改善については特にいいアイデアを出せる気もしない。 現バージョンのMessagePackについてとりたてて不満はなかったが、最近文字列型を加えよう、あるいはもっと楽に文字列を扱えるようにしよう、という話が出てきた。JSON的に楽に扱えて更にバイナリデータを投入できるフォーマットの需要そのものは理解できる
MessagePackフォーマット仕様にTimestamp型を追加 - Blog by Sadayuki Furuhashi
MessagePackフォーマット仕様のPull Request #209をマージし、MessagePackにTimestamp型を追加しました。 ※この記事の英語版は XXX にあります（翻訳中） Extension型の型コード -1 として定義されているため、後方互換性が維持されています。つまり、既にExtension型に対応しているデシリアライザであれば、Timestamp型を使用して作成されたデータを、Timestamp型に対応していない古いデシリアライズで読み出すことができます。 新しいTimestamp型には timestamp 32、timestamp 64、timestamp 96 の3つのフォーマットがあり、よく使う値をより少ないバイト数で保存できるようになっています。例えば、1970年〜2106年までの時刻で、秒までの精度しか持たない時刻であれば、合計6バイトで保存でき
WebSocketでブラウザにプッシュ配信する - MessagePack-RPC＋Rev-WebSocket - Blog by Sadayuki Furuhashi
先日、WebSocketのサーバライブラリ Rev-WebSocket をリリースしました。 前回のエントリではブラウザ同士で通信するチャットアプリケーションを紹介しましたが、実際にはTwitterクローラやWebアプリケーションなど、別のプログラムと連携してブラウザにプッシュ配信したくなると思います。 つまり↓このように、任意のプログラムからWebSocketサーバを経由して、ブラウザにデータをプッシュ配信します： プッシュ配信したいアプリケーションと WebSocket サーバの間は MessagePack-RPC で繋ぎます。 Rev-WebSocket と MessagePack-RPC は相性が良く、簡単に統合することができます*1。 アプリケーションから WebSocket サーバを経由してブラウザにデータを配信するコードは、↓このようになります。 require 'rubyg
と、いうものを作りました。MessagePackのC#版です。以前に作ったZeroFormatterのコードをベースに、バイナリの読み書きをMsgPackのフォーマットに差し替えたものになります。MsgPackのライブラリはすでにあるじゃん(MsgPack-Cli)！ってことなんですが、パフォーマンスにかなり差があります。 neuecc/MessagePack-CSharp JSON.NET（スタンダードで、豊富なAPIを持ってる）に対するJil（スピード特化、APIは必要十分はあるけれどJSON.NETほどではない）のようなものと思ってください。とはいえ、生のまま使っても問題は出ない（デフォルトのままで最高速が出るようにチューニングしてある）でしょうし、カスタマイズの口自体も十分用意してあります！詳しくは「拡張」の項で説明しますが、既に私自身が他のライブラリへの対応・インメモリデータベー
並列メッセージングフレームワーク「MessagePack-RPC for C++」リリース - Blog by Sadayuki Furuhashi
分散KVS kumofs のコードは、全体で約2万行です。 そのうち、ネットワークI/Oやプロトコルに関するコードは約1万行で、全体の約半分を占めています。 並列イベント駆動I/Oフレームワーク「mpio」リリース ネットワークアプリケーションを実装する上で、もっとも大きな障壁は、ネットワークI/Oとプロトコルです。 では、それが両方ともフレームワークでサポートされ、コードを書く必要が無くなったらどうでしょうか？ 54行で簡単な分散KVSを実装したり、140行で分散リアルタイム検索エンジンを実装することができます。すなわち、インデックス作成サーバ、検索サーバ、DBサーバなど、多数のサーバが連携し、スケールアウトの恩恵を得ることができるネットワークアプリケーションを、１台のホスト上で動作する並列アプリケーションとほぼ同じように書くことができます。 実装上の問題から解放されれば、並列性や耐障害
MessagePack-RPCのプロトコル仕様（ドラフト）と実装例 - Blog by Sadayuki Furuhashi
以前に書いた MessagePack RPC プロトコル は少し古くなってしまったので、ここでまとめ直しておこうと思います。 MessagePack-RPCのプロトコルは、非同期型の呼び出しができる点（非同期プロトコル）が大きな特徴となっています。複数のサーバが相互に通信し合ったり、通信と計算をオーバーラップさせて高速化を図ったりするような、高度なネットワークアプリケーションを実装しやすくなります。 RPCライブラリと言うよりも、シンプルな非同期メッセージングライブラリと言えます。 ここではMessagePack-RPCのプロトコル仕様と、以上の特徴を活かせるような実装例も合わせて紹介します。 基本仕様：MessagePack-RPC specification version 0.1 MessagePack-RPCのプロトコルは、メソッドの呼び出すRequestメッセージと、それに対する
こんにちは。開発担当の森本です。 今回は、Fenrir Pass Connect を支える技術にちょっと関係のある、 web などを介してデータを交換するときの話をしたいと思います。 データ構造の共通化 → 実装も共通化できる プログラム間、端末同士、Web 経由などでデータを送ったり送られたりするときに、データは決まったフォーマットで送られる必要が有ります。 たとえば、今表示しているこのページでは、本文は HTML、画像は PNG などのバイナリフォーマット、web API との連携などは JSON や XML、スタイルシートや JavaScript はそれぞれ独自のテキストフォーマットが使用されています。 一般的なプロダクトでは上記のうち、XML や JSON が使用される事が多いと思います。 これらのフォーマットは普及率が高いため情報も多く、多くの処理系で枯れて安定した実装があるため
Javaのシリアライザーをいろいろ試してみる（Java標準、Kryo、MessagePack、Protocol Buffers、JBoss Marshalling） - CLOVER🍀
少しシリアライズ関係のライブラリを目にする機会がありまして、そういえばこういうまとめ記事あったなぁということを思い出しました。 MessagePack、Kryo、Protocol Buffersなどのシリアライザーのパフォーマンス比較 http://blog.katty.in/4567 気にはなっていたものの、実際にこれらのライブラリを使ってコードを書いたことはなかったので（Protocol Buffersは除く）、いい機会だなと思い試してみました。 今回は、以下について書いていきます。 Java標準 Kryo MassagePack Protocol Buffers JBoss Marshalling 最後の方にかなり個人的な趣向が入っていますが、気にしない方向で…。Java標準が入っているのは、とりあえずといった感じで。 ここから、簡単にシリアライザーごとにシリアライズ対象のクラスと、
最近Railsがガンガン出力するproduction.logを解析してどのアクションがリクエスト多いのか、DBがボトルネックになってるアクションはないか、などを調べているんですが、production.logがどんどん肥大化して、解析ツールの開発イテレーションを回す際の効率が悪くなってきました。 また似たようなツールをやたらめったらコピペで作ってきたため、開発効率も悪くなってきたので、ここでAPIを整理しつつ、あわよくばログをなめる部分を高速化できないものかと考えました。 シンプルに正規表現をつかって変化する箇所を切り出していたのですが、これではかなり重いのは自明ですし、がんばって文字列をパースするパーサを作ってもrubyではあまりスピードは出なそう、でもrubyで書きたいし.... ということで、一度パースしたデータを読込みに効率よさそうな形式に変換することで、次以降の解析を高速化しよう
Ruby で MessagePack-RPC - Blog by Sadayuki Furuhashi
高速なオブジェクトシリアライズ形式 MessagePack をプロトコルに採用したRPCライブラリをリリースしました。 Ruby を使って簡単にRPCサーバーやクライアントを実装できます。 msgpack-rpc MessagePack-RPC プロトコルは既にkumofsやクラスタ管理ツール「clx」などで利用しており、高速なサーバーの実装にも便利ツールの実装にも、幅広く使えるシンプルなプロトコル仕様になっています。 clxを使うと複数のサーバーをグループに分けて、同じグループに属するサーバーに対して同じコマンドを実行できます。コマンドは並列して実行されるので、ファイル転送（rsync）のような時間のかかるコマンドでも快適に使えます。 clxのコアは汎用的なRPCサーバーで、RPC以外の機能はすべてモジュールとして実装されています。モジュールは起動時に登録できるほか、実行中でも追加でき、
フォーマットの変更は、ユーザーに対して基本的に不利益をあたえる バージョン情報が含まれているフォーマットならば問題はすくないユーザーはなにも考えたくないから汎用フォーマットをつかう できるだけなにも考えたくないゆるふわプログラマーがほとんどなのですYAML をみよ バージョンの差異と、プラットフォームごとの実装の非互換によってわけわかめである初期の時点でまともに実装できている処理系がすくなかったバージョン2を現在まともに処理できているのは libyaml ぐらいではないか? これはフォーマットの複雑さによるところが大きい1のライブラリと2のライブラリ、ユーザーには見分けがつかない状況 YAML::XS が2 で YAML.pm が 1 とどうしてわかる?非互換や、ユーザーのプログラムがこわれる変更は、まあなしね。Data::MessagePack2 とかがでたときに、たとえば AnyEve
私は、多数の大容量のデータをあちこちに移動させなければならない(クライアント端末をHTTP APIに接続してデータを取得します)ような特殊な使用事例を扱っています。なぜだか ^(1) 、転送形式にはJSONが使われていました。ある時、その大容量のデータが、さらに巨大になったのです。数百メガバイトどころではありません。JSONのデコード処理を実行すると大量のRAMが使用されることが分かりました。たった240MBのJSONペイロードで4.4GBですよ。信じられません。 ^(2) 組み込みのJSONライブラリを使っていて、まず「もっと性能の良いJSONパーサがあるはずだ」と思いました。そんなわけで、計測を始めたのです。 さて、メモリ使用量の計測はやっかいです。 ps コマンドを使ったり、 /proc/<pid> を見たりすることはできますが、断片的なスナップショットが得られるだけで、実際の最大使
Fluentd w/ Ruby 2.0.0-p0 のメモリ使用量 (追記: w/ msgpack v0.5.4) - tagomorisのメモ置き場
いくつかFluentdのベンチマークをとらないとなー、そういえばRuby 2.0.0-p0も出ましたね、ということでベンチマーク取ろうと思ってあれこれ作業してたらなんか変なのを見付けたのでとりあえず記録。 なおベンチマークの結果については、いろいろ取りかたを考え直す必要があるのでまたこんど。 概要 Fluentd の動作環境が Ruby 2.0.0-p0 with jemalloc なケースで Ruby 1.9.3-p392 に較べて大幅に大幅にメモリを食う上、負荷を停止した時にも何かよくわからない挙動を示す。 jemalloc を使わないケースだと 1.9.3 とほとんど変わらないと思われる挙動で jemalloc の必要性が無くなったとかいうわけではない。 詳細 ベンチマークは あるサーバ(4core HT, 16GB RAM)に立てた Fluentd に対し、別のサーバ(同一サブネッ
Cache::Memcached::Fastの高速化
一番簡単に高速化するには シリアライザをData::MesagePackにするとよいかもしれない。 #! /usr/bin/perl use strict; use warnings; use Cache::Memcached::Fast; use Data::MessagePack; use Benchmark qw/timethese/; my $normal = Cache::Memcached::Fast->new({ servers => ['127.0.0.1:11211'], serialize_methods => [ \&Storable::freeze, \&Storable::thaw ], }); my $msgpack = Cache::Memcached::Fast->new({ servers => ['127.0.0.1:11211'], serialize
はじめに Protocol Buffers でググると「Protocol Buffersは遅い」という記事が上位にヒットし、（記事公開から7年以上立っている現在でも）これをもって「Protocol Buffers は遅くて非効率」という印象を持たれることが多いようです。 しかし、この記事のベンチマーク実装は Protocol Buffers の性能特性を十分に活かしきれておらず、不公平な比較となっているように思われます。この記事では Protocol Buffers 寄りの視点で Protocol Buffers と MessagePack 比較を試みます。 で、遅いんですか？ わかりません。遅いんじゃないでしょうか？（！） 今回はシリアライズ速度の比較は行いません。計測がめんどくさいのと、私は ScalaPB を使っているので C++ 実装のシリアライズ速度にあまり興味がないためです。
140文字を超えちゃうので、こちらで。 id:viver さんの MessagePack を JavaScript で実装してみました。 HOT TO USE <script src="misc/msgpack.js"></script> <script src="misc/utf8.js"></script> <script> var pack = msgpack.pack("こんにちはこんにちは"); alert(msgpack.unpack(pack)); // こんにちはこんにちは </script> 現時点の仕様 / 制限事項 仕様 msgpack.pack(data:Mix):ByteArray で、data に指定されたオブジェクトをエンコードし、ByteArray( [数値, ...] ) を返します。 文字列は UTF8 な raw data として数値化します。 エンコ
cuzic です。 MessagePack の JavaScript 実装を作成しましたので、公開しました。 GitHub においております。 サーバ側で生成した MessagePack の文字列をクライアント側の JavaScript で、 var data = MessagePack.unpack(unescape("%a1%61")); alert(a); と書けば Ruby で 'a'.to_msgpack に相当する MessagePack のシリアリゼーション結果を変数 data に格納します。 現在は以下の状態です。 MessagePack 形式のデコードが可能。 整数、nil 、false 、true、浮動小数点、文字列、ハッシュ、配列 に対応 FireFox 3.6.3 と IE 8.0.6 で動作検証を実施。正常動作を確認。 作成した理由としては、以下の理由です。 最近
msgpack-lite ピュアJavaScript実装の速いMessagePackライブラリ - Qiita
MessagePack のエンコード・デコードを行う Node.js 用の JavaScript のライブラリを公開しました。 エンコード処理は、C++ で書かれた msgpack ライブラリよりも速いです。（Node.js v0.10.40） デコード処理も、他の Pure JavaScript のライブラリより速いです。 デモ → http://kawanet.github.io/msgpack-lite/ 使い方 エンコード処理：（JSオブジェクトをBufferに変換） var msgpack = require("msgpack-lite"); var buffer = msgpack.encode({"foo": "bar"}); // => 81 A3 66 6F 6F A3 62 61 72
こんにちは。takei-hです。 ちょっと時間が経ってしまったのですが、アシアル株式会社、KLab株式会社の合同勉強会でMessagePackとPHP Extensionについて発表しましたので、資料を公開します。 Php Meets Messagepack View more documents from Hideyuki Takei. また、PHP Extensionもだいたい形になったので、公開します。 MessagePack PHP Extensionのダウンロード ソースを解凍した後、インストールは以下のコマンドで。 $ ./configure $ make $ sudo make install そして、php.iniに以下の行を追加します。 extension=msgpack.so これで準備完了です。 主に、ruby版のライブラリを参考にしています。使い勝手はPHPのjso
RubyKaigi2010でトークしてきました - The MessagePack Project - Blog by Sadayuki Furuhashi
つくばで開かれたRubyKaigi2010で、多言語間通信ライブラリ MessagePack についてLTしてきました。 音声付きの動画をニコニコ動画で見られます（スバラシイ！）。ぴったり5分に収まりました^^; 発表資料（PDF） 発表資料（クリックで進む動画） Twitterを見る限りでは評判も良かったようで、ひとまず安心しています。 説明が足りなかった部分もあるので、ここで補足しておきます。 JSONと比べてどれくらい小さくなるの？ ある日のTwitterのpublic_timelineを使って比較してみたところ、JSONでは31KBだったものが、MessagePackでシリアライズし直すと25KBになり、約19%削減されました。 ただミニブログサービス「Amebaなう」に…等々の話にもあるように、「MessagePackを使えば必ず大幅にサイズ圧縮に成功する」という訳ではないです。
Msgpack can't differentiate between raw binary data and text strings · Issue #121 · msgpack/msgpack
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
MessagePack for Java ついに 0.6 リリース！ - Blog by Sadayuki Furuhashi
先日の fluent に引き続き、新しいソフトウェアのリリースです。 満を持して、MessagePack for Java 0.6 をリリースしました！ 9ヶ月ぶりのメジャーバージョンアップです。 以前のバージョン 0.5 の API をすべて見直し、互換性を維持しながらも、数多くの機能を新たに搭載しました。動的オブジェクトAPI や リフレクション機能の強化、JRubyとの連携、JSONサポート などなど。もちろん、性能も大きく向上しています。 このバージョン 0.6 のリリースによって、MessagePack の応用範囲は大きく広がります。MessagePackは、クラウドシステムからモバイルデバイスデバイスまで、多種多様なシステムの連携と統合をサポートする、新しいデータ表現形式です。 さて、新機能の詳細をご覧下さい： JSONシリアライザ･デシリアライザを統合 MessagePack
node.jsのパフォーマンスを調べてみた
こんばんは。 巷では「node.jsは軽量かつ高速だよー」と噂されてるにもかかわらず、色々探しても、どれほど軽量でどれほど高速なのかを検証しているところが日本語ではあまり見つかりません。 その為、今回は、WebSocketを用いたsocket.ioの速度/メモリ使用量調査をしてみました。また、msgpack-rpc改変版をWebSocketの上に実装したバージョンと比較もしてみました。 テストは以下ですが、次の注意点を踏まえてお試しください。 デモは、どちらもさくらのVPS 512、CentOS 5.7, kernel 2.6.18-274.18.1.el5 x86_64上に構築してあります。 node.jsのバージョンは、v0.6.12。socket.ioのバージョンは、0.9.1-1を利用していますので、最新版はより良いパフォーマンスが出るかもしれません。 socket-io版は、デモ
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
Cloudflare is now well into its 6th year and providing authoritative DNS has been a core part of infrastructure from the start. We’ve since grown to be the largest and one of the fastest managed DNS services on the Internet, hosting DNS for nearly 100,000 of the Alexa top 1M sites and over 6 million other web properties – or DNS zones. CC-BY 2.0 image by Steve Jurvetson Today Cloudflare’s DNS serv
MessagePackって何? MessagePackとはなにかといいますと、JSON互換の異なる言語間でデータ交換するためのシリアライズフォーマットです。JSONのような型を扱え、 JSONよりコンパクトで、速いと言われています。(mrubyではまだ性能評価していないので、今後やってみたいと思います。) ログコレクターで有名なfluentdというミドルウェアで使用されています。 MessagePack for mruby 今回、MessagePack for ruby v 0.5.5からmrubyにGEMとして移植しました。すべて移植したわけではないので、α版というところでしょうか。 MessagePack#pack,MessagePack#unpackメソッドでだいたいの型を使用出来るようになっています。 次の例は配列をシリアライズして、MessagePack#unpackメソッドでデ
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
Kyoto Tycoon に MessagePack-RPC をプラグインして Java から使う - Blog by Sadayuki Furuhashi
Tokyo Cabinet を始めとする Tokyo シリーズの作者として知られる平林幹雄さんですが、Tokyo シリーズに続く新製品として、Kyoto シリーズがリリースされています。 Kyoto Tycoon（以下KT）は、ネットワーク経由で使えるデータベースサーバで、Tokyo Tyrantの後継製品に当たります*1。 KT は HTTP ベースのプロトコルで操作することができますが、別のプロトコルを追加することもできます。 実際に memcached プロトコルのプラグインが標準でバンドルされています。（memcachedプロトコルをKTにプラグインする） と言うわけで、KT を MessagePack-RPC で使えるようにするプラグインを書いてみました。github からダウンロードできます。 kt-msgpack kt-msgpack downloads MessagePac
Confusion about IETF draft for a fork of MessagePack
Confusion about IETF draft for a fork of MessagePack In this article, I’d like to discuss the current situation concerning the MessagePack open source project and potential standardization by the Internet Engineering Task Force (IETF). The appropriateness of the recent activity surrounding this OSS project and the standardization draft proposal is of perplexing nature, so I hope to shed some light
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
MessagePack: It's like JSON. but fast and small.
Geekなぺーじ:MessagePackがIETF標準化に巻き込まれてる件について
MessagePackが文字列とバイナリをわけないのは問題？
Treasure Dataを支える技術 - MessagePack編
Blog by Sadayuki Furuhashi
MessagePackのIETFへの提案に関する困惑 - たごもりすメモ
neue cc - C#(.NET, .NET Core, Unity, Xamarin)用の新しい高速なMessagePack実装
XML より JSON より MessagePack が便利です
RailsのログファイルをMessagePackで超高速解析!｜TechRacho by BPS株式会社
汎用データフォーマットにたいする雑感 - tokuhirom's blog
PythonのJSONパーサのメモリ使用量と処理時間を比較してみる | POSTD
Protocol Buffersは遅いのか - Qiita
JavaScript で MessagePack を実装してみた - latest log
MessagePack-JS - プログラミングは素晴らしい
アシアルKLab合同勉強会で発表しました: MessagePackのPHP Extensionについて
msgpack/msgpack#121を3行でまとめるブログ
How we made our DNS stack 3x faster
mrubyでMessagePackを作った！ - 涼風コンピュータblog
MessagePack for Ruby version 5