ざっくり概要 ピークで3000req / sec 毎分コンテンツ更新要求 コンテンツ更新の際は他所からデータをapi経由で受け取る コンテンツ更新にはTheSchwartzを使用 なコンテンツを色々してきたログ。 尚、ここに書く技術は大半が周囲のギークな方々にサポートしてもらったもので、僕自身が何かしたわけではない。残念すぎる。 構成 internet -> www(squid -> apache) -> app(memcached -> app) -> db フロントエンド wwwサーバがapacheとsquidを動かしている。apacheがリクエストを受け、squidのキャッシュが有ればそれを返し、無ければバックエンドのappサーバへproxy。 バックエンド appサーバがmemcachedとアプリを動かしている。 それぞれ冗長化してるけど、リクエスト数の割に台数は少ない。 技術があ
チームルンバとして@kazph @kitanpとisuconに参加してきました！ ■準備 まずは前回のisucon関連の記事を読みあさる 最初はrubyで行こうかーとなっていたけど、前回のみたらかなり初期性能に差があったのでperlに決定 memcachedはどこでつかうんだろうねー リバプロにnginxを立てて、nginxからmemcachedにアクセスして返すのが良さげ（前回のfujiwaraさんの構成を見て） 更新があったタイミングでアプリからmemcachedにセットしよう ■当日 初ヒカリエにテンション上がる NHNさんの受付でムーンと写真を撮る 写真をひと通り撮り終えて席につく 課題発表。今回の課題はチケット販売システム。 スタート！ パスワードのIをl と勘違いしてログインできない（しかも全員w） @kitanpさんに鍵登録、リバプロのnginxとmemcachedをインスト
潔く。 思った事 ソースを見て DB重そう 参照系クエリでJOINしまくってるなー recunt_soldとか 更新系重そうだなー IS NULL ORDER BY RAND appがstatic file返してるの無駄だなー front endがapacheなのはやめたほうがよさそう 最終的にはmemcachedにレスポンス突っ込んでnginxのmemcachedモジュールで返せればいいなー recunt_soldは別パスにしてSSIで分離出来るとキャッシュの寿命分けられていいなー 負荷を見て やっぱりDB重いなー これいっそRedisとかで書き換える方がいいのでは でもRedis普段使ってないし怖いなー ベンチ直後のappが重い？ いろいろ疑ってみたが原因わからず DBIをdisconnectしてみたが、遅くなった いつの間にか解消されててなぞ rev負荷あんま無いなー appたててし
認証が不要で、結果をJSONPで返してくれるAPI。大体は高速化の為にmemcachedを使用し、cacheが存在すればcacheから、存在しなければDB等から引いてcacheに入れ、その後結果を返す設計になってるはず。 URL: http://api.example.com/count?user_id=12345&entry_id=12345&callback=hoge response: hoge({"status":"success", "count":1000});みたいなの。ほとんどの場合cacheにHitするので一瞬でresponseが返るけど、あまりに簡単なお仕事過ぎてそれの為にmod_perlのプロセスを使うのがもったいない。特に1日数千万回アクセスされるようなAPIだと積もり積もってすごい負荷に。 responseに使うJSONをそのままcacheに入れて、Tokyo T
nginx+memcachedがめちゃ気になったので試してみました。 元ネタは下記です。 A 53,900% speedup: Nginx, Drupal, and Memcache bring concurrency up and page load time way down | TechnoSophos nginxをリバースプロキシに利用した構成で、バックエンドの出力をmemcachedにキャッシュしておけば、次回リクエストではnginxがそのキャッシュを読み取ってそのまま出力してくれます。 つまりバックエンドにリクエストを経由させずにnginxから即出力するのでかなりの高速化が見込めるという優れものです。 リンク先ではバックエンドにDrupalを利用していたのですが、ここではCakePHPを利用してみます。 1. 全体構成 リバースプロキシにnginx(Port: 80)を使い、バ
ISUCONに行ってきました。社内での事前βテストに参加して問題を知っていたので出場はせず。社内β参加を持ちかけられたときは、正直「めんどくせーなｗ」が素直な感想だったんですが、実際にやってみるとスコアがリアルタイムにわかる＆ちょっとずつ自分のスコアが上がっていくってのは楽しくて、わりと本気でチューニングしてしまいました。 さて、本戦でも14時頃からお遊び用としてサーバー一式が解放されたので、大人げも無くそこで112500req/minをたたき出して参加者のやる気を削いだ（・・と懇親会で言われました。色々すいません！）構成について。 reverse proxy nginx(1.0.5) ngx_http_memcached + ngx_http_ssi_filter + ngx_http_scgi + ngx_http_upstream_keepalive(3rd party plugin
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く