星期二, 七月 24, 2007
改變referer資料顯示筆數，降低文章顯示錯誤機率
優格網今天改變了一項設定，將輸出外部來源網址referer（反向連結）的筆數限制為30筆或20筆，改善部份熱門文章（含有大量referer資料）讀取很長一段時間後，產生php error的問題。
從mysql資料庫將referer資料select出來後，只取count最高的前30個或20個，避免先前全部的referer資料啪啦啪啦都列出來的恐怖結果。
也許可以考慮，定期清理count只有1的referer資料，進一步減少db中的資料筆數，才有辦法進一步改善資料庫的效能。
另外，重新整理了一些垃圾迴響或引用會出現的過濾字串，多半是藥物名稱、性相關的字彙。
由 ivan 發表於 8:46 PM | 文章分類: 站務相關
從mysql資料庫將referer資料select出來後，只取count最高的前30個或20個，避免先前全部的referer資料啪啦啪啦都列出來的恐怖結果。
也許可以考慮，定期清理count只有1的referer資料，進一步減少db中的資料筆數，才有辦法進一步改善資料庫的效能。
另外，重新整理了一些垃圾迴響或引用會出現的過濾字串，多半是藥物名稱、性相關的字彙。
由 ivan 發表於 8:46 PM | 文章分類: 站務相關
迴響留言
然後 如果 javascript 檢測 沒問題 多送一個 param .... 然後如果 server side 看到這個 param 就可以用一個大if 直接跳過 檢查 文字的 code
但這樣也相對 比較 open to hack ? (不是真的 hack)
(是說 自己手動 加這個 param 然後 惡意亂發廣告)
anyway ... just a few thoughts
但這樣也相對 比較 open to hack ? (不是真的 hack)
(是說 自己手動 加這個 param 然後 惡意亂發廣告)
anyway ... just a few thoughts
其實 也可以 用 文件方式 儲存 referrer ....
就是每篇文章 創一個 檔案 儲存 referrer
(不見得 比較好 ... 比較 多檔案 同時 難 manage 些就是了
但是速度應該會快些, 不單是access , 同時 add new entry 也比較快)
不過 硬碟 相對的 fragment 也多些 o.o
就是每篇文章 創一個 檔案 儲存 referrer
(不見得 比較好 ... 比較 多檔案 同時 難 manage 些就是了
但是速度應該會快些, 不單是access , 同時 add new entry 也比較快)
不過 硬碟 相對的 fragment 也多些 o.o
妳是說 整體的 count 伺服器 wise
還是說 單一篇數 的 count increment 麻煩?
基本上 忘記 是在 多少的 數字上
但是 在一定的 資料範圍內
利用 explode implode 然後用 檔案儲存資料
會比 用 mysql 還來的快
記得 好像是什麼 1000 x 1000 table 那類型的
也是 網路上有文章 自己有做過測試
可是 真的 也是 一年半前的事情了
(當時在製作地圖時 有做研究 最後 決定是 用檔案器統 儲存 地圖 然後 基本上 儲存時 以 php format 儲存
要讀取時 直接 include 就 讀取 variable 了)
畢竟 在 mysql 資料多後
O 應該會呈現 非直線性的增加
不過 mysql 也算是 發展很完善的 所以 應該不會太糟
還是說 單一篇數 的 count increment 麻煩?
基本上 忘記 是在 多少的 數字上
但是 在一定的 資料範圍內
利用 explode implode 然後用 檔案儲存資料
會比 用 mysql 還來的快
記得 好像是什麼 1000 x 1000 table 那類型的
也是 網路上有文章 自己有做過測試
可是 真的 也是 一年半前的事情了
(當時在製作地圖時 有做研究 最後 決定是 用檔案器統 儲存 地圖 然後 基本上 儲存時 以 php format 儲存
要讀取時 直接 include 就 讀取 variable 了)
畢竟 在 mysql 資料多後
O 應該會呈現 非直線性的增加
不過 mysql 也算是 發展很完善的 所以 應該不會太糟
張貼迴響:
引用列表
本篇文章引用網址: http://yblog.org/api/trackback/?id=7275
沒有引用
本篇文章引用網址: http://yblog.org/api/trackback/?id=7275
沒有引用
訪客來源網址(僅列最多的10個外部來源):
- https://www.google.com.tw/ (6)
- http://www.google.com.t...9xzrnrcronvfvngm (1)
- http://tw.search.yahoo....start=1&b=11 (1)
- http://www.google.com.t...w&sig2=26p6w (1)
- http://www.google.com/u...xzrnrcronvfvngma (1)
- http://www.google.com/u...2f7275&ei=k7 (1)
- http://www.google.com.t...l1mm9xzrnrcronvf (1)
- http://tw.search.yahoo....ei=utf-8&v=0 (1)
- http://www.google.com.t...g&usg=afqjcn (1)
- http://www.google.com.t...g&usg=afqjcn (1)
- http://www.google.com/u...ig2=ddigvuvxs3xh (1)
- http://www.google.com.t...9dcximfk50br4xow (1)
- http://tw.search.yahoo....&fr=ush_dict (1)
- yblog.org (1)
- http://www.bing.com/sea...blh&filt=all (1)
然後 使用 regex
當使用者要 submit 時 可以自動 popup 要求更改
或是 像google 那樣 (基本上也是自己猜測 google 那樣做)
用 domain / ip score 的方式 或者是 引用的辭彙裡面 有 兩個 或是 三個 以上的 禁字 才完全 block
(如此一來 可以 稍加 增長 禁字庫的長度 同時應可 更有效防範)
(trade-off 就是 processing time 了)
不過 我想 score 還是比較適合 email .... 論壇的應用上 似乎 不大
76.199.7.* | 標記為廣告 | 回應此篇迴響