Rails キャッシング - takt@Wiki
インターネット上の大規模サイトの多くはインタープリター型言語を使っています。そうしたサイトは、Ruby と同じ方式、つまりクラスター化され、何も共有しないアーキテクチャーを採用しています。そしてキャッシュも行っています。大部分のサイトでは、可能な限り最大のパフォーマンスを得るために、効果的なキャッシング方法を必要としています。そして Rails 開発者も、そうした方式に従い始めています。 単純な Rails アプリケーションの作成に役立つ記事は、何十というほどあります。このシリーズでは、単純なブログを作成するという基礎を越え、すべての Rails サイトが解決すべき問題に入り込みます。ここでは Rails の最適化方法や、サイトをより安定にするための方法について学びます。また、Rails の基本的な制約を、プラグインを追加することで回避する方法も学びます。このシリーズの各記事を読み終わるご
acts_as_authenticated & acts_as_cachedのセットがいい感じ
acts_as_authenticated Plugin + acts_as_cachedのセットがいい感じです。 最近は、LoginEngineよりもActs As Authenticatedというプラグインを使ってます。（Acts as Authenticated in Plugins） Acts as Authenticated in Pluginsの下の方を見ていただければわかる通り、このプラグインではパスワード変更とかパスワードリセット、メールアドレス変更などの一通りのアカウント管理のメソッド実装が、サイト上に公開されています。さらに自動ログイン機能が最初から付いてたりと、手軽にしっかりアカウント周りの機能が実装できるので、めんどくさがりの僕はかなり重宝してます。 ただし、このプラグインは唯一欠点があるのです。 それは、「ログインが要求されるアクションへの毎アクセスごとに、ユー
[Rails] *.rhtmlでrender :partialを使うとめちゃくちゃ遅いので対処する方法
Posted by masuidrive Mon, 01 Jan 2007 11:37:00 GMT 過去に作ったRailsアプリがどれも遅いので、色々ベンチマークなどを取ってみると、予想以上にviewの部分が遅いことが判明。 なんでveiwが遅いのか、さらに調べていくとrender :partial => “hogehoge”がかなり遅いっぽい。特にループの内側にあったり:collectionを指定すると激遅。ソースを読んでないので全くの憶測だけど、毎回ERBをファイルから評価してないか？ 試しに、1つのページに5つある(うち一つは:collectionで10回ループ) render :partialを手で展開して実行してみると、apachebenchで1.3倍(19reqs/sec→24.7reqs/sec)になった。これはかなり効果が高いんだけど、メンテナンス性が著しく落ちるので、他
クラブ・ラボ
このサイトは、 KLab株式会社が公開しているオープンソースソフトウェアや実験サービスについて紹介するはずだけど ただいま引越中です。
ヽ( ・∀・)ノくまくまー(2007-05-20)Rails勉強会@東京#18 後半: 今だからこそ運用環境を考える
● [Rails] Rails勉強会@東京#18 前半: QueryCache / MMC 後半: 今だからこそ運用環境を考える に参加。 ● 前半: QueryCache / MMC QueryCache とは、AR.find の結果を memcached を用いてキャッシュする plugin。(rakuto 作) rakuto式 QueryCache の課題 with_scope どうする？ memcache のキー 削除戦略 1は、AR.find の引数だけを見てキャッシュのキーを作成しているため、with_scope と混ぜるな危険。解決策の1つは「キャッシュするレイヤーを select_xxx まで引き下げる」こと。そうすると find_by_sql まで対象に入るという嬉しい副作用もある。ただその場合、キャッシュの対象も同レイヤーにするとARオブジェクトでなく生の結果セットにな
naoyaのはてなダイアリー - Linuxのページキャッシュ
世間では PHP が、Perl が、と盛り上がっているようですが空気を読まずまたカーネルの話です。今回はページキャッシュについて。 /dev/shm に参照系ＤＢを持っていくと I/O 負荷が激減した件（当たり前だけど） - drk7jp で、ディスク上にあったファイルを /dev/shm (tmpfs) に移したら I/O 待ちがなくなって負荷がさがった、ということなんですがおそらくこれは tmpfs に置く必要はないかなと思います。Linux (に限らず他の OS もそうですが) にはディスクの内容を一度読んだらそれはカーネルがキャッシュして、二度目以降はメモリから読む機構 = ページキャッシュがあります。tmpfs にデータを載せることができた、ということは物理メモリの容量に収まるだけのデータサイズかと思うので、放っておけば該当のファイルの内容すべてがメモリ上にキャッシュされて io
Ruby on Railsのパフォーマンス向上に関する10のtips:
という記事があった、色々と面白かったので訳してみる。良いとこも悪いとこもあると思うけど参考までにメモとして 元記事：Top 10 Ruby on Rails performance tips Rubyの基本的なコードを見直してみる自分で作ったクラスよりもできるだけ組み込みのクラスライブラリを使うできるだけ正規表現を使用する、文字列処理にコストの高いループは避けるREXMLは遅いのでLibxmlライブラリを使用する （Cで書かれたXMLパーサらしい、環境に依存するのは嫌かもしれない）if文の多用は避ける、例えば||=を使う ( z||="none" で unless(z){ z = "none" })Hashはコストが高いので他のデータ構造を検討してみる （でも使いたいときあるよね？）キャッシュを有効活用する acts_as_cached でModelをキャッシュ化してみる(PDF資料
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
IBM Developer