フラグメントキャッシュをRailsで使う。 - kaeruspoon
Railsでは三つのキャッシュ機能があります。ページキャッシュにアクションキャッシュ、そしてフラグメントキャッシュです。今回はフラグメントキャッシュを使ってみました。
使いかたはとても簡単で、キャッシュしたいビューの部分をcacheブロックに入れるだけ。
via kaeruspoon.net
Explore Posterous
Search posterous
Search all posts and users. Type a name, type a favorite song title, whatever! See what comes up.
More posterous blogs
Here are posterous posts filed under cache...
Rails 2.1の主な変更点を整理 - ひげろぐ
キャッシュ機構の強化 – Better caching
フラグメントキャッシュなどのキャッシュは今まではファイルに保存するしかなかったけれども、これをメモリやmemcacheやdrbなど他のキャッシュストアにも保存できるようになった。
定義はconfig/environment.rbなどで以下のように
ActionController::Base.cache_store = :memory_store ActionController::Base.cache_store = :file_store, "/path/to/cache/directory" ActionController::Base.cache_store = :drb_store, "druby://localhost:9192" ActionController::Base.cache_store = :mem_cache_store, "localhost"何も指定しないときのデフォルトは:memory_storeになる。
このほかにも自作のキャッシュストアを作成して使うこともできる。
参考
via brass.to
Caching in SilverLight 3
To sum it up, it looks like the touted GPU acceleration features of silverlight 3 aren't as big as the marketing hype, but they are pretty useful. Looks like it effectively prevents re-renders of static elements, but still allows for transforms. I'll have to play around with this to see how it effects sprites in games.
http://pagebrooks.com/archive/2009/03/31/bitmap-caching-in-silverlight-3.aspx
ヽ( ・∀・)ノくまくまー(2005-07-13)
Action caching 詳細
Pageと同じでキャッシュ対象はアクションの出力全部であるが、Fragment(後述)として保存される点と参照時に ActionPack を経由する点が Page とは異なる。つまり、キャッシュを渡す前に ActionPack へ制御がうつるため、そこで認証や制限を行う事が可能になる。
class BerryzController before_filter :authenticate, :except => :show # filter は全部にかかるので show は除外する caches_page :show caches_action :edit def authenticate unless @request.env["REMOTE_HOST"] == "127.0.0.1" redirect_to "/404.html" end end endキャッシュの削除には expire_action メソッドを利用する。
via wota.jp
Structure of Intel CPU Caches
This is a good article about Intel CPU cache organization.
I am posting this here to keep a track of this article and share with others.
"This post shows briefly how CPU caches are organized in modern Intel processors. Cache discussions often lack concrete examples, obfuscating the simple concepts involved. Or maybe my pretty little head is slow. At any rate, here’s half the story on how a Core 2 L1 cache is accessed:"
http://duartes.org/gustavo/blog/post/intel-cpu-caches
Discussion on Hacker News (Ycombinator) http://news.ycombinator.com/item?id=431263
- AD
jCaches功能更新
本来这些功能是上周就已经完成的，一直到最近才有时间开始整理，最近太忙了
这次我给 jCaches 加入了一些新功能，因为当时在做一个功能，这个功能上面用户会动态加一些数据，以二维表格形式体现的，但这些数据又不能马上存到数据库，只能临时存放在客户端，直到当他点击“保存”按钮时才一起将这些数据提交到服务端存放。
做这个功能时我首先想到了我的 jCaches 用它将数据以对象的方式零时存放起来，再通过JSON.js 把这个对象序列化成字符串，再提交到服务端。果然很快这样的功能就实现了，我在JS里面定义了一个跟表格字段相对应的类，每次用户加入一条数据时创建一个对象，服务端也同样建相同结构的类，最终把提交上来的列化成字符串转成对象。再加上 jCaches 的管理，功能很快实现。
同时也跟 jCaches 加入了一些新的功能：
- datas 属性,缓存的数据数组列表，只读，修改它不会影响原数据
- length 属性，目前已存放的个数
- size() 方法,得到目前的缓存个数
- remove(id String) - 根据“标识ID”删除缓存信息，参数：id 标识ID
- each(callback Function) - 遍历Cache列表, callback 回调函数,带有一个参数返回，是当前Cache的value
Faster Customization Changes
We’ve been getting a lot of feedback on hab.la recently and we noticed that many of you thought customization was broken. Customization was working, but had a bit of lag due to some very aggressive (and somewhat poorly designed) caching.
I just pushed out a set of changes to the site that will make customization changes take affect instantly :-).
This fix should also fix the problem where the “One more step to go” message gets shown even after the first step was complete. Only the site operator would see this message, but I am sure it made things seem like they were messed up.
For those of you new to Hab.la, you can customize the messages shown in the Hab.la window as well as the colors and positioning of the Hab.la window in the customize section of your My Hab.la page.
There are a lot of exciting things happening here at Hab.la. Kevin should be blogging about some of his contributions to the excitement soon :-)
As lighttpd as a feather as quick as a wink
Ok, that title was pretty lame. I digress.
Here’s the news: we’ve migrated hab.la’s front end proxy servers on to lighttpd so now we have joined the in crowd for web2.0 applications (delicious .. anyone who does ruby …etc ). As an end user you should see a general speed increase for most aspects of hab.la. However, this migration was done to specifically address some of the problems apache experiences when dealing with large number of passive connections. [Jeremy Zawodny has a great post on dealing with slow HTTP clients – which is very similar to what hab.la appears to be from the proxy server point of view at http://jeremy.zawodny.com/blog/archives/008496.html. You might want to also read about cache performance issues http://www.mnot.net/blog/2006/08/21/caching_performance ]
Ideally we should remove the proxy server from the mix and you should hit the RPC server directly, either by running the RPC server on port 80 (requires root) or by some sort of TCP level routing trick to tunnel requests around from port 80 to port 8000. But, that’s a fix for another day.
