cumiki.com - プログラミング リソースおよび情報
This webpage was generated by the domain owner using Sedo Domain Parking. Disclaimer: Sedo maintains no relationship with third party advertisers. Reference to any specific service or trade mark is not controlled by Sedo nor does it constitute or imply its association, endorsement or recommendation.
キャッシュ機能 - 気にすんな
Railsのキャッシュは、以下の３種類があるんだねー ページキャッシュ（caches_pageメソッド）は、アクションを丸ごとキャッシュ アクションキャッシュ（caches_actionメソッド）は、フィルタだけは実行して、ページ全体をキャッシュ フラグメントキャッシュ（chcheヘルパー）は、ページの断片(フラグメント)単位でキャッシュ まずは、事前設定として、config/environments/development.rbの、以下の2か所のキャッシュ設定を有効にする # config.cache_classes = false config.cache_classes = true ---- 中略 ---------------------------- # config.action_controller.perform_caching = false config.action
Railsでmemcacheを使ってobjectをキャッシュ - Qiita
Page Cache Action Cache Fragment Cache とかじゃなくて普通にObjectをStoreしたいんだよって時に。
# Dalliのsession_id作成部分をざっくり読む[途中まで] - Qiita
def get_session(env, sid) unless sid and session = @pool.get(sid) sid, session = generate_sid, {} unless @pool.add(sid, session) raise "Session collision on '#{sid.inspect}'" end end [sid, session] end ここでセッションIDを作成してるっぽい。 unless sid and session = @pool.get(sid)ここでsidの有無を確認していて、存在しなかった場合はgenerate_sidを呼び出してsidを作成してるっぽい。
![# Dalliのsession_id作成部分をざっくり読む[途中まで] - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/70fe6fbc96512ddc6e81807e95103280d83a9826/height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fcdn.qiita.com%252Fassets%252Fpublic%252Farticle-ogp-background-412672c5f0600ab9a64263b751f1bc81.png%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTk3MiZoPTM3OCZ0eHQ9JTIzJTIwRGFsbGklRTMlODElQUVzZXNzaW9uX2lkJUU0JUJEJTlDJUU2JTg4JTkwJUU5JTgzJUE4JUU1JTg4JTg2JUUzJTgyJTkyJUUzJTgxJTk2JUUzJTgxJUEzJUUzJTgxJThGJUUzJTgyJThBJUU4JUFBJUFEJUUzJTgyJTgwJTVCJUU5JTgwJTk0JUU0JUI4JUFEJUUzJTgxJUJFJUUzJTgxJUE3JTVEJnR4dC1hbGlnbj1sZWZ0JTJDdG9wJnR4dC1jb2xvcj0lMjMxRTIxMjEmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9NTYmcz0wNWFkZTc5MTkyYTM3YWExYWNhNDc4M2E4YjYwMGI0MA%26mark-x%3D142%26mark-y%3D57%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZoPTc2Jnc9NzcwJnR4dD0lNDBzb3BsYW5hJnR4dC1jb2xvcj0lMjMxRTIxMjEmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9MzYmdHh0LWFsaWduPWxlZnQlMkN0b3Amcz1mYjQxZTU5ZTM5ZjkzOGYzYjhlMjRiMDA2ODBkODFhOA%26blend-x%3D142%26blend-y%3D486%26blend-mode%3Dnormal%26s%3Dd3b3252bd7214ecbf5a75272192186e3)
Rack::Session::Dalliのexpire_afterには要注意 - Qiita
Rack::Session::Dalliは、Rack::Session::Memcacheの代わりに使える素敵なモジュールです。 Rack::Session::Dalliに指定するexpire_afterの最大値は2591999 (60 * 60 * 24 * 30 - 1)です。これを超えた値を指定すると、memcachedに値が保存されずに即座にexpireしてしまうようです。例外も何も出ないので注意が必要。 例 class MyApp < Sinatra::Base use Rack::Session::Dalli, memcache_server: 'localhost:11211', domain: 'mydomain.com', path: '/', expire_after: 60 * 60 * 24 * 30 - 1 # 2592000未満の値にしよう! # (略) end
Railsのaction cache（アクション キャッシュ）を使ってみる - プログラマでありたい
とあるRailsで構築しているサイトでパフォーマンス改善をしたくて、キャッシュ機構の導入を検討しました。キャッシュ機構は色々なポイントがありますが、ざっくり分類すれば言って下記の３点でしょう。 １．Webサーバ側によるコンテンツキャッシュ ２．アプリケーションサーバ側による処理のキャッシュ ３．DB側のデータのキャッシュ １のWebサーバのコンテンツキャッシュについては、Apacheのキャッシュであったりリバースプロキシによるキャッシュも含めてもよいでしょう。３のDBのキャッシュ機能については、クエリキャッシュだったりその他の色々なキャッシュを想定して頂ければと思います。最近すっかり定着したMemcached等のKVSのキャッシュは、２と３の中間になるんですかね。 そして、２のアプリケーションのキャッシュ機能についてです。今回のケースでは認証等が絡むので、１のWebサーバ側でのキャッシュの
caching strategies
Webアプリケーションは、ロードに予期せぬ時間を要するページを、少しばかり抱えてしまうことが良くあります。 Heroku上では、長時間のリクエストがdynoと結びつき、アプリケーションのパフォーマンスに深刻な影響を与えます。 どのページ、どのデータベースが低速なのかを判断するために、[New Relic]を使用して下さい。 （Webトランザクションとデータベースのタブを参照して下さい。） 一番時間を要するリクエストを試験してみて下さい。もし、原因が低速なデータベース、またはAPIのトランザクションにあるのであれば、 情報をキャッシュするために、低水準のキャッシュ（例えば、`Rails.cache.read/write/fetch`）を使用して下さい。 Herokuは、'automagic'のcache-moneyやcache_fuのようなライブラリを使わないことを推奨します。 我々は、容易
rack cache memcached static assets rails31
少し複雑になりますけど、静的アセットを供給するためには、CDNを使用することが最も効率的なオプションとなります。 詳細はこちらの記事を参照して下さい。 CDN asset host Ruby on Railsのアプリケーションでは、Cedar stack上にアセットを効率的に供給するために Rack::Cacheを使うべきです。 適切なRack::Cacheの使用は、レスポンスタイムを改善し、ロードを減らし、アプリケーションを通して静的アセットを 供給する際に重要となります。 この記事は、Rack::Cacheを使ったキャッシュのアセットの概念についてサマライズしています。 また、Rails 3.1のアプリケーションとアセットパイプラインの適切な設定に関しても、手順を示します。 この記事で参照するアプリケーションのサンプルコードは、 GitHub上に置かれており、 http://rack-
Webアプリにおけるキャッシュ。オレオレ事例 - ゆーすけべー日記
Webアプリにおいて、アクセスやデータ量が多く/大きくなってくると、 バックエンドのパフォーマンスが低下しがちです。 MySQLなどのRDBMSにデータを置いている場合は適切に クエリーを改善する、インデックスを張る、といった策で解決する場合もありますが、 キャッシュを効果的に利用することでより高負荷に対応できる可能性があります。 また、外部APIへの問い合わせなど、どうしてもネットワークや他のリソースのレスポンスタイムに 引きずられる部分に関しては情報を手元にキャッシュしておくと何かとよいでしょう。 今回はWebアプリケーションのレイヤーで最近僕がどのようにキャッシュを使っているのか？ の事例を紹介しつつまとめてみたいと思います。 キャッシュについてとその基本 そもそもキャッシュとは、簡単にふわっと表現するならば、 「一時的に情報を手元の近い場所に置いておいて利用する手法、もしくはその一
RailsとDalliでMemcached体験 - 思ったこと
こんばんわ。 「〜NoSQL（KVS）大集合～」とかそれっぽい勉強会に参加して 概要とかダメなトコとかイケてるトコなんとなく知ってたんですが 食わず嫌いしてました。 入れてみたらとっても快適だった。 導入もすぐだったのでメモ。 Macに入れる brew install memcached GemfileにDalliを入れる gem 'dalli' // memcachedとかmemcache-clientって選択肢あったけど // Herokuがオススメしてるのでこれに。 config/environments/の使う環境に以下を記述 config.cache_store = :dalli_store ここで細かい設定も可能 config.cache_store = :dalli_store, 'cache-1.example.com', 'cache-2.example.com', {
Gem Dailliでキャッシュ(memcache)を有効活用してRailsを高速化！ - 酒と泪とRubyとRailsと
Gem Dailliでキャッシュ(memcache)を有効活用してRailsを高速化！ Feb 9th, 2013 Tweet 『Dalli』はRailsでmemcachedを使うためのクライアントです。特にWebアプリではアクセスが増えるとデータベース側の負荷が高まり、速度が遅くなってしまいます。そういった問題を解決する手段の一つとしてキャッシュを有効活用するのはすごく大切です！ ちなみにWebアプリにおけるキャッシュ。オレオレ事例 - ゆーすけべー日記のキャッシュについての説明がすごくわかりやすいです！ memcacheとは？ memcacheはデータベースを用いた Web サイトを高速化するために良く用いられるメモリにデータを格納するタイプのKey-Valueストアです。Webアプリでメモリにキャッシュするタイプでは最も有名だと思います。 Macへのインストール MacでHomebr
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
hima-j.in
3 step Memcache install in ubuntu with rails binding