最近低GIダイエットのブログを中心に書いている気がしますが、年末ということで少し時間ができたので前々から導入しようと思っていたKyotoTycoonのメッセージキューを試すことにしました。メッセージキューによる非同期処理といえば、Q4MとかActiveMQをよく使っていていますが、これもKyotoTycoonでいいんじゃない？と思うこの頃です。 何よりmemcachedプロトコルで動作するのがとても助かりますよね。 今回の内容はこちらです。 ktserver起動ファイル(マスター) ktserver起動ファイル(スレーブ) ジョブの登録(PHP) ジョブの取得と削除(PHP) ベンチマークの結果 テスト中に気になったこと kctのデフラグ Net_KyotoTycoonでキューの件数を取得する(PHP) 参考 memcachedプロトコルでメッセージキューを実現する http://fall
memcachedプロトコルでメッセージキューが実現できるという話を前回したが、今回はその具体的な使用方法を解説してみる。 サーバを起動する まずはサーバを起動しないと始まらない。典型的には以下のコマンドで立ち上げるとよい。 $ ktserver -th 1 -ls \ -plsv /usr/local/libexec/ktplugservmemc.so \ -plex 'port=11211#tout=30#thnum=16#opts=fq#qtout=10' \ 'casket.kct#ktopts=p' 「-th 1」でメインサーバのスレッド数を1にしている。最新版からはデフォルトで16スレッドを立てるのだが、アプリ側からはメインのサーバにはアクセスしないだろうから、1個あればよい。「-ls」はログレベルをSYSTEMに設定。「-plsv ...」では、memachedプラガブルサー
・KyotoCabinet 1.2.43 (srpm) ・KyotoTycoon 0.9.33 (srpm) いつも通りなんですが、 KyotoTycoon の方にはビルドフラグがあります。 んで、毎度のことですが Tycoon をビルドする前に Cabinet をビルドしてくださいな。 まあ Develop 環境でビルドして rpm 作ってから Staging に Uvh すると思うんで、 あんまり気にしてないんですけど本番環境でビルドしようとか考えたら色々マズイです。 Tycoon のビルドで一度 Cabinet を rpm -ve しないと怒られます。 Require の書き方が間違ってるのかな、これ‥‥
前回の記事にて、Kyoto Tycoonでメッセージキューを実現する方法について述べた。今回は、それを実運用にて使いやすくするための諸機能について説明する。みんな大好きなmemcachedプロトコルでメッセージキューを実現してみよう。 ジョブキューとメッセージキュー どうでもいい話ではあるが、ジョブキューおよびメッセージキューという用語はよく混同して使ってしまう。俺定義では、ジョブキューは「ジョブ管理機能」という目的をたまたまキュー構造に基づいて実装しているものであり、メッセージキューはキュー構造に基づく非同期メッセージング機構であって用途は特に限定しない。つまりメッセージキューをジョブキューを実装するのに使うこともあるが、それ以外の用途にもメッセージキューは使われる。またジョブキューをメッセージキューに基づかないで同期的に実装することもできる。 きっと偉い学者さんがどこかでちゃんとした定
いわゆるkey-value storeを使っている際に、レコードの挿入もしくは更新を検知して即座に何らかの処理を行いたくなることはないだろうか。俺はあんまりないけど、結構そういう質問が来るので、きっと巷にはそういう要求があるのだろう。Kyoto Cabinetでそれを実現してみた。 ジョブキュー もうちょい具体的な例を挙げると、ジョブキューである。ここで、「foo」という名前のタスクを考えてみる。読み出し側（ワーカ）は、適当な名前をつけた条件変数を常に監視していて、そこにシグナルが飛んできたら即座にレコードを取得して処理を行いたい。しかし、「一定の間隔毎にレコードの検索を繰返して発見したら処理を行う」というポーリングスタイルにはしたくない。操作にどうしてもタイムラグが出るし、ポーリングのための無駄なトラフィックが発生するからだ。 シグナル待機処理と該当レコードの取得処理を行う擬似コードは以
国内だけでなく国外(なぜか主に中国語)でもまだrepcachedについて言及してるのをちらほら見かけるのですが、repcachedはmemcached 1.2.8ベースですし(memcached 1.4.5に対応してる人もいるようですが)いまならKyoto Tycoon使えばいいんじゃないかと思うのです。 Kyoto Tycoonなら: memcachedプロトコルプラグインを使えば、Kyoto Tycoonがそのままmemcachedの代替になる（memcachedプロトコルを喋るクライアントコードはそのままでよい） Tokyo Tyrantと違ってexpireもOK memcachedの代替が目的なら、速いオンメモリDB(StashDBとか)でOK 非同期レプリケーションもできる ホットスタンバイ側のサーバリソースが無駄に思うなら、keyに応じてmodとかでリクエストするサーバを2台の
チャオ！みんな、Kyoto Tycoonライフをエンジョイしてるかい！？ 今日はKTライフを満喫してるミーからの運用TIPSアンドソーオンをお届けするＹＯ！ kchashmgrとktremotemgrコマンドの補完 人間の脳活動のピークは22歳の今日このごろ、みなさんいかがおすごし？ もうね、ミーは全然コマンドオプションとか覚えられないからシェル(bash)で補完しまくってるＹＯ！ kchashmgrとktremotemgrだけだしオプション網羅してないし補完ルールもアレだけどオープン＆シェアなマインドとガッツで気になる人はfork & push！ Nagiosで死活監視 ナギオス！みんな使ってるよね？ ミーはcheck_httpでKTのHTTP RPCのechoにアクセスしてデッドオアアライブの監視してる！ define command { command_name check_kyot
前回の記事でカウンタを SQLite3 に移行することに成功したのだが、なんか妙にパフォーマンスが安定しない。何度か F5 で読み込み直すと 100msec ちょっとぐらいで返ってきたり（それでも遅いけど）、500msec 以上掛かったり。 もしかして SQLite2 だと問題ないのかなと思い結局 php-sqlite を入れたりして実験してみると、確かに SQLite2 のコードの方が安定して 100msec を切っていた（それでも同時アクセスが集中すると簡単に遅くなっていく）。 アクセスが少ないんだからそれでいいじゃんという話もあるが、せっかく好き放題できるサーバなのだから好き放題やってみようと思い、Kyoto Tycoon のサーバを立てて PHP からアクセスさせてみることにした。こんなアクセスの少ないサイトに対してこんな豪華なものが使えるなんて幸せだ。 mikio さんのチュート
libkyototycoon をつかって 5分で C++ で RPC サーバーを書く方法 ちょっとした RPC サーバーを C/C++ でかきたいな、なんてケースはままあるわけですが、そんなときに便利なライブラリがあったので紹介します。 KyotoTycoon をつかうと、TSVRPC over HTTP な RPC サーバーが超簡単にかけて便利だった。libkyototycoon は GPL だけど、それが問題にならない場合なら、とてもいいとおもう。商用ライセンスかえるならそれもいいとおもう。 RPC サーバーとしては他にもいくつか実装があるんだけど、HTTP の上で実装されているから、デバッグが容易だったりとか、直接 telnet ではなしたりとか tcpdump できたりして、いろいろ便利なので、よいとおもう。 SConstruct でビルドルールをかいてから e = Environ
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
Kyoto TycoonのRESTfulインターフェイスを使って各種スクリプト言語から操作するためのメモ。 背景 Kyoto TycoonはHTTPを喋るデータベースサーバなので、HTTPを喋れるクライアントライブラリを備える全ての言語処理系から利用することができる。とはいえ、HTTPの知識が多少なりとも求められるというのは煩雑である。なので、プロトコルを隠蔽したアクセスライブラリが欲しい。C++版は俺が実装したAPIがKT本体に同梱されているが、その他の言語に関しては、その言語毎の有志に実装をお任せすることにしている。 しかし、そのようなAPI出てきていない環境では生HTTPクライアントライブラリを使うしかない。といっても、KTのRESTfulインターフェイスを使うと、基本的なアクセスライブラリであれば非常に簡単に書くことができる。ここでは、RubyとPython3の例を挙げてみる。 R
TTではpure Ruby版とpure Perl版のクライアントライブラリを自分で実装していたが、KTでは各種pure実装は自分では書かないことにする。私はC++版のクライアントライブラリを作成しメンテナンスするが、その他の言語に関しては、その言語で生活していて腕に覚えのある方々にお任せしたい。その前提として、プロトコルを明らかにしておく必要がある。英文の仕様書を後で書くが、そのたたき台としてまずは日本語で書いてみる。 ---- 概要 KTのサーバプログラム（ktserver）は、HTTPに基づいてクライアントと通信を行う。デフォルトのサービスポートは1978番だが、ユーザの設定によって変わることもある。サーバは、HTTP/1.0およびHTTP/1.1のリクエストを解釈することができ、それに対応するレスポンスを返す。 HTTP/1.1のリクエストにおいてContent-Typeヘッダの値が
node-kyoto-tycoon http://github.com/swdyh/node-kyoto-tycoon KyotoTycoonのNode.js用ライブラリを作りました。まだだいぶ荒削りな状態で、KyotoTycoonのAPIを簡単にラップした感じのものです。APIも変わるかもしれないし、バグもたぶんあると思いますが試してみてください。 Node.jsが新しめでないとHTTPのKeep-Aliveが使えないので、古いNode.jsを使っている場合は、新しいNode.jsを入れて使ってください。(Keep-Aliveが使えなくても動きますが、カーソル関連は使えないと思います) インストール npmを使う % npm install kyoto-tycoonソースから % git clone http://github.com/swdyh/node-kyoto-tycoon.gi
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く