タグ

関連タグで絞り込む (26)

タグの絞り込みを解除

Kyoto Tycoonに関するyassのブックマーク (8)

  • - KyotoTycoon's Performance on SSDs

    yass
    yass 2013/10/26
    " Though the performance of KT is fantastic when the dataset is small and fits in memory, it seems that as the data size grows you can’t expect much more than 2-2.5k writes per second. "
    リンク

  • kyototycoonのLuaスクリプティング拡張をLuaJITにしてみた

    yass
    yass 2013/10/26
    "kyototycoonでLuaJITでパフォーマンスが向上できるかどうか検証してみた結果、性能向上が見込めることがわかりました。前回の検証と今回の検証により、kyoto系のプロダクトにおいて、LuaJITにスイッチした方が性能見込めそう"
    リンク

  • 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

    Kyoto Tycoon に MessagePack-RPC をプラグインして Java から使う - Blog by Sadayuki Furuhashi

  • pixivのデータストア/キャッシュ戦略 その3 - pixiv engineering blog

    HHKB Professional Type-Sが欲しいインフラ兼ソフトウェアエンジニアのbokkoです。 普段はHHKB Proの日本語配列キーボードを愛用しています。英語配列は苦手です。このことを同僚のエンジニアに言うとジト目で見つめられ・・・睨みつけられること請け合いです。 本連載の最後となる今回はpixivのデータストア/キャッシュ戦略を支える周辺ミドルウェアについて解説していきます。 memcachedからKyotoTycoonへ移行した際に発生した問題 前回の記事の最後にもあったようにpixivではAPの数だけあったmemcachedへのリクエストを少数のKyotoTycoonにまとめたことで一部のKyotoTycoonサーバへのTCPコネクション数が爆発してKyotoTycoonサーバのCPUやメモリリソースには余裕があるのにネットワークで詰まるという問題が起こりました。 元

  • ドラゴンクエストXは「世界は一つ」を実現するためにどのようなサーバ構成にしているのか？

    スクウェア・エニックスの人気RPG「ドラゴンクエスト」シリーズの最新作「ドラゴンクエストX（ドラクエ10）」はシリーズ初のオンライン作品となりましたが、その舞台裏は一体どうなっていたのか。ゲームの世界観を支えるサーバシステムがどのように構成されているのかということや、ドラゴンクエストⅩならではの仕組みや機能から開発の苦労話まで、株式会社スクウェア・エニックス開発部プログラマ森山朋輝さんが語っています。 タイトル | CEDEC 2012 | Computer Entertaintment Developers Conference http://cedec.cesa.or.jp/2012/program/NW/C12_P0040.html 森山朋輝： 皆様、本日はお集まり頂きどうもありがとうございます。このセッションを担当させて頂きます、株式会社スクウェア・エニックス開発部所属の森山朋輝と

    ドラゴンクエストXは「世界は一つ」を実現するためにどのようなサーバ構成にしているのか？

  • memcachedからKyotoTycoonへ

    Editor's Notes\n \n\n \n\n \n\n \n\n \n\n \n\n \n\n \n\n \n\n \n\n \n\n \n\n \n\n \n\n \n\n \n\n \n\n \n\n \n\n \n\n \n\n \n\n \n\n \n\n \n\n \n\n \n\n \n\n \n\n \n\n \n\n \n\n \n\n \n\n \n\n \n\n \n\n \n\n \n\n \n\n \n\n \n\n \n\n \n\n \n\n \n\n \n\n \n\n \n

    memcachedからKyotoTycoonへ

  • 開発メモ: DBサーバのnoreplyオプションによる高速化

    Kyoto Tycoonやmemcachedにてnoreplyオプションを使ってパフォーマンスを上げる話。 noreplyの功罪 DBに対する更新操作はその成否を真偽値などとして呼出側に返すのが通常であるが、それを省略することでパフォーマンスを上げることができる。memcachedではnoreplyオプションとして知られている。KTの最新版からは、memcachedプラグインと独自バイナリプロトコルでもnoreplyオプションをサポートすることにした。 noreplyを有効にするとなぜ高速化するのか。クライアントはクエリをsendしただけで、recvをせずに次の処理に移れるからだ。sendシステムコールに渡したデータはカーネルが非同期に処理するので、カーネルとアプリケーションは並列に処理を進めることができる。recvをした場合にはその時点で両者の待ち合わせが発生してしまうのだが、それをしな

  • 開発メモ: Kyoto Tycoonのプロトコル再設計

    HTTPベースで任意のRPCコールができるように、プロトコルを汎用化したい。KT以外のユースケースでも、パラメータ等の解析部分は同じコードを使いまわしたい。その考察。 動機：実装を簡単にしたい 前回述べたHTTPServerクラスを作ったことで、HTTPベースのサービスを作るのが非常に容易になった。そしてその目的は、Kyoto Cabinetのデータベースを操作する各種メソッドをRPCで操作することである。でも、まてよ、「RPCで操作する」ってとこだけ抜き出してもう一段抽象化した方が、実装が簡単になるし、後々のメンテナンス性が良さそうだ。そうしよう。 RPCといっても処理の流れが同期なのか非同期なのかとか、データの受け渡しがブロックなのか、エラーの返却はどうするのかといった決定の組み合わせによって多様性があるわけだが、今回は最も単純な組み合わせを選択する。すなわち、リクエスト受信からレスポ

  • 1

お知らせ

もっと読む

公式Twitter

  • @HatenaBookmark

    リリース、障害情報などのサービスのお知らせ

  • @hatebu

    最新の人気エントリーの配信

はてなブックマーク

公式Twitter

はてなのサービス

  • App Storeからダウンロード
  • Google Playで手に入れよう
Copyright © 2005-2024 Hatena. All Rights Reserved.