[tDiary] tDiary のキャッシュを memcached にした, [rails][ruby] rails-dev-box に出した pull request が reject された, [tdiary] tDiary を r.. - HsbtDiary(2013-01-14)
■ [tDiary] tDiary のキャッシュを memcached にした tDiary には erb コンパイル済みのソースなんかをキャッシュとして一時ファイルに書き出していて、再利用するという仕組みがあるんだけど、つい先日 PaaS 対応したついでに作ったキャッシュを memcached に保存するコードをこの日記に入れてみた。 使い方は以下の3行を tdiary.conf に書くだけ。 require 'tdiary/io/cache/memcached' require 'tdiary/io/default' @io_class = DefaultIO ベンチは取ってないけど体感でだいぶ早くなったような気がするので、中々便利かも。 ■ [rails][ruby] rails-dev-box に出した pull request が reject された rails-dev-box
![[tDiary] tDiary のキャッシュを memcached にした, [rails][ruby] rails-dev-box に出した pull request が reject された, [tdiary] tDiary を r.. - HsbtDiary(2013-01-14)](https://cdn-ak-scissors.b.st-hatena.com/image/square/8cab6183abe73ade0ce0a24c302ac36ee5c17b43/height=288;version=1;width=512/https%3A%2F%2Fwww.hsbt.org%2Fdiary%2Ftheme%2Fogimage.png)
高負荷サイトのボトルネックを見つけるには : DSAS開発者の部屋
はじめに アクセスが急増すると、応答時間が著しく悪化するサイトはありませんか？ 普段は200ミリ秒以内で安定してアクセスをさばいているのに、イベントやらキャンペーンやらを開始した瞬間から、普段の２倍や３倍のアクセスが殺到し、その結果、レスポンスタイムが3秒とか9秒とかかかるようになってしまうことってありますよね。 あるサイトの実状 つい先日まで、そんなサイトが私の目の前にもありました。自社で運営している某ソーシャル系のサイトなんですが、イベント開始時刻と同時にアクセス数が急増するのです。とはいえ、所詮は普段の2倍とか3倍程度の数なのだから、少なくとも1秒以内にレスポンスを返せるくらいの性能は維持したいものです。 しかし実際は困ったことに、応答に3秒以上もかかってしまう処理が大量に発生してしまう状況に陥ってしまっていました。これはきっと、どこかにボトルネックがあるに違いありません。 仮説を立
CakePHPとnginx+memcachedで手軽にキャッシュを活用する
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)を使い、バ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
BIGLOBEクラウドホスティング
Fixing MemCache IO timeout for memcache-client
