TechCrunchThe central processing unit (CPU) and the graphics processing unit (GPU) handle different types of data. The CPU is used in almost all devices including computers, cellphones, tablets, smartwatches an
【メモ】memcacedのバックアップとしてTokyoTyrantを使う
現在あるシステムで、memcachedのバックアップとしてTokyoTyrantを利用しています。 以下は、主要な部分だけを抜粋したコードです。 $key = 'hello'; //Pecl::memcached $value = MyMemcached::get($key); if($value === false): //memcacheから取得できないときはTokyoTyrantからの取得を試みる MyTokyoTyrant::initialize(); if(MyTokyoTyrant::getEnabled() === true): $value = MyTokyoTyrant::get($key); $hasTTCache = (!$value) ? false : true; else: $hasTTCache = false; endif; //TokyoTyrantからも
第4回 Redisを用いたアプリケーション開発（2） | gihyo.jp
前回紹介したRedisのLIST型に続き、今回はSET型とSORTED SET型について、その構造とWebアプリケーション開発への応用を紹介します。 SET型の構造 RedisのSET型は、重複のない文字列要素の集合を保持するデータ型です。Javaのコレクションフレームワークをご存知の方には、「HashSet」のようなもの、と想像していただくと分かりやすいかと思います。 LIST型のPUSHやPOPと同様、SET型への追加／削除の時間計算量はO(1)となり、理論上はサイズに関係なく一定時間で操作できることになります。実際、ニコニコ生放送のシステムでは、要素数にして数万規模のSET型に対して、分間数千～数万回の追加操作を行っています。 一見、SET型のデータ構造は単純すぎて、アプリケーションで活用する機会が想像しにくいかもれません。RedisにはHash型という連想配列のように使えるデータ
手始めにMembase調べてみた - Web屋の人の日記 || WebJourney 開発ログ
Python Hackathon で BigCouch の発表をする予定だったんですが、Membase と CouchOne の合併をうけて、、、Membase のほうに俄然興味が映ってしまったのでその辺をささっと調べて発表してきました。 内容は薄いです... membaseView more presentations from yssk22. が、、、、もうね、 StrategicSqilte3 とかどの辺がStrategicなのかと小一時間問い詰めたいぐらいorzな気分です。 Moxi Proxy とか vBucket Client とかそれなりにいい感じでなので、仕事でも使おうかなーって思ってたんですが、、、すまん、SQLite3 の運用設計なんてしたくないから使いません*1。 *1:この手のセッション系KVSで重要なのってデータのExpirationとそれに伴うメモリ/ディスクか
Emerge Technology: membase、めちゃくちゃ遅い？いや、遅すぎ？
最近はいろいろとベンチマーク的なことをやったりして、それが仕事なのか趣味なのかよく分からない日々を送っています。しかも、会社の人はみんな忙しそうにしているので、暇そうなのはCTOと僕ぐらいです。そんなこんなで、自分で手を動かしている訳ですが・・・。 さて、membaseが気になるお年頃で、membaseとmemcacheで速度比較してみました。以前、repcacheとの速度比較もしたのですが、データをなくしちゃったというか、ほとんど劣化しなかったので、とってもつまらなかったです。membaseもmemcache互換プロトコルをサポートしてくるので、コードを書き換える必要はありません。会社で試したときは、うまく動かなかったのですが、家ではちゃんと動いています。何が違うのでしょう？ まず、membaseの独断と偏見の特徴は次の３つです。 クラスタ構成 memcache互換プロトコル レプリケー
Emerge Technology: MongoDBのshardとreplica その1
生まれ変わった「Days of Liris」。プログラミングのこと、Pythonのこと、気になったソフトウェアのこと、身の回りのこと、いろんなこと。など まず、MongoDBの負荷分散、もしくは、データの分散については、shardingという仕組みで行っています。shard自体は通常のmongodのプロセスです。各shardには、データがchunkの単位で保存されています。chunkは、キーに対してデータの連続性が確保されているので、連続したデータへのアクセスが高速化されます。一つのmongodのプロセスにchunk単位以上のデータがセットされたり、サーバの数が増加すると、他のshardにデータが自動的に移動します。この仕組みだけをみると、shardは増えることはあっても、減るのは苦手のように聞こえます。 shardが自動でデータの分散を行ったり、どこにデータがあるのかを見つけるためにco
Emerge Technology: MongoDBとmemcacheのパフォーマンス比較
生まれ変わった「Days of Liris」。プログラミングのこと、Pythonのこと、気になったソフトウェアのこと、身の回りのこと、いろんなこと。など 単純なキー・バリューの構造でパフォーマンスがどうなのか、memcacheと比較してみました。mongodbとmemcachedはそれぞれ、ローカルの一台のちびえあたんの中で動かしています。比較するためのコードは、次のところにあります。 MongoDB用のコード Memcache用のコード Javaのコードは恥ずかしいので公開しません。計測はちびえあたんでやっています。 やっていることは、MongoDBではnoとbodyというフィールドにデータを設定して、10000件登録しています。memcacheでも同様にキーにシーケンシャルな数、値にMongoDBでセットしたものと同じ値をいれてaddしています。 登録にかかる時間は、MongoDBでは
データベースサーバを複数台構成とか2010年代には流行らない - blog.nomadscafe.jp
奥一穂さんの「ウェブアプリケーションサーバを複数台構成とか2010年代には流行らない」にフォローのような感じで。 例によってタイトルは煽りです。 奥一穂さんのエントリーでは、「5,000万PV/Month」という見積もりでアプリケーションサーバの台数を1台と計算していますが、これからは「1,000万PV/Day」を超えるサイトが多く生まれてくると予想しています。どんなサイトかというと、mixiアプリやモバゲーなどにソーシャルゲームを提供するサイトです。 ソーシャルゲームサイトのキャパシティプランニングについては中澤さんのエントリーが参考になります。 The Art of モバゲー Capacity Planning The Art of Mixi-mobile-appli Capacity Planning 最も人気がでた場合には数千万から数億PV/Dayという数字がならんでいます。怖い怖
ウェブアプリケーションサーバを複数台構成とか2010年代には流行らない - kazuhoのメモ置き場
タイトルは煽り入ってますが。 仮に動的ページを生成するのにかかる時間が1秒、そのうちデータベースやmemcached等リモートサーバへの問い合わせ時間を除くいたCPUの処理時間が0.1秒とする。また、ピークのリクエスト処理量は、平均の２倍とする。 そうすると、クアッドコアのアプリケーションサーバで処理できるリクエストは、 4 core * 10 reqs/sec * 86,400 sec/day * 30 day/mon / 2 = 51,840,000 reqs/mon と、約5,000万PV/月を１台で捌けることになる。 CPUが動いている時間は全処理時間の10倍と仮定したわけだから、アプリケーションサーバの最大同時接続数は 4 core * 10 = 40 程度あればいいことになる。実際には、安全係数を２倍かけて 80 とか。リクエストの処理に必要なメモリ量を 100MB とすると、
Mozilla Re-Mix: ボタン一つでIPを偽装してブラウジングを行うことができるFirefoxアドオン「Stealthy」
ウェブサービスによっては、アクセスしたユーザーのIPアドレスから国などの情報を取得し、そのユーザーに適したページを表示したり、アクセスを制限したりすることがあります。 インターネットラジオサービスの「Pandora」などは日本からのアクセスができないことなどがよく知られていますね。 また、一部の海外ブランド直販サイトでは、米国本店で安く買い物をしようとしてアクセスしても日本法人のサイトにリダイレクトされてしまい、日本の価格でしか購入ができないようになっていたりもします。 しかし、このような処理がされても使いたいサービスがあるでしょうし、お得に買い物をしたいこともあるでしょう。 Firefoxユーザーなら、このようなIPによる制限を回避するようなことはなんでもない作業だと思いますが、設定がややこしかったり、サーバを探したりするのが面倒だったりしますね。 Firefoxに「Stealthy」と
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
DISQUS | Turn Blog Comments into a Webwide Discussion with a Powerful Comment System
Welcome to nginx!