What have you found for these years?

2008-12-31

cache (3)

神木,我有病。居然一直在寫筆記,還搞到半夜。

anyway, 快放假了...?

搞這 cache 實在大傷腦筋啊,日前開會決議不要用掃的,
在每次有新留言時更新 count 即可。當下不覺得有什麼問題,
於是著手開始進行。不過現在又覺得好像不大對?這種事也發生過
好多次了,所以說才覺得其實當面討論會遺漏掉很多事啊 @@

因為現在是在有追加留言時重算 count,
但如果一直都沒有呢?假設三十天過去沒有任何留言,
那所有的 count 都應該歸零才是。

也就是說,假設現在有某個相片衝到 10000 留言,
然後七天之內都不要有任何新留言,那他就永遠停在第一名了。

只是這時如果忽然有一個人過來留言,那 count 又會降到 1,
當然也就變成倒數第二名了。(第一當然是 0 的)

也就是說,定期更新所有的 count 感覺還是必要的。
至少已經比 page view 好處理了,畢竟 comments 有紀錄,
而 page view 沒有... page view 要留紀錄的話,
豈非操死 database? 當然其他手段,例如先存 session
定期灌回、page cache, 等等又是另外一回事。

我是覺得定期掃沒啥啦... 大不了就掃最新的 5000 筆,
太老的上排行榜也沒意思啊,又不是在玩遊戲,讓老人可以獨霸排行?
更何況天梯(game ladder)也是會砍掉重練啊,這也很平常。



不過值得筆記的應該是中途試了非常多東西。
懶得再重寫一次了,參考:cross repository query path?
發現跨 mysql database 的速度實在是很慢,就算 DataMapper 支援,
大概也是不能用。所以就把 comments_count 裝回 :default repo,
命名為 cache_comments_count, 表示 cache 開頭的是不得不放在這,
其實也是可以 tuncate 掉的東西。

然後 controller 裡其實沒辦法用 Sync.comments_count(resource),
因為這是 DataMapper 的東西,上次測試在 rails 裡面跑問題一堆,
所以大概還是得避開 dm 的東西,只好重寫一份在 Cache::CommentsCount 裡面。

然後忽然想到,那是不是本來就應該寫在 model 上?
不過這是小問題,不值得特別拿出來講就是了。

總之就是測試暫時沒問題啦。雖然這看起來很怪:

Photo.repository(:cache) do
Photo.for_public
end

會變成從 :cache 裡抽出 photo 但是判斷是用 :default 的 permission.
正好在同一個 database(schema) 下不會有問題就是了...?

相較之下 AR 真的很殘廢,有點 poor man's solution 的味道...
複雜一點的操作根本都要下海寫 SQL... 我也居然從完全不懂看到似懂非懂了...

*

page view 大概就暫緩吧

0 retries:

Post a Comment

All texts are licensed under CC Attribution 3.0