很多人發現到Fx3有嚴重的"發狂"問題, 自己一開始就沒去注意, 直到現在我才想也許該正視一下, 至少想要知道這究竟是什麼情形, 所以就趁這次...弄個"大~"實驗看看

這期間看到反應這問題的, 我想大部分的人大概存了至少幾十個即時書籤, 也許上百個也有吧? 有個問題是, 這問題發生後維持的時間究竟是多少, 會不會不同的(操作)階段有不同的現象, 這一直都不是很明確. 為了假設真的發生時能有個足夠突顯問題的結果, 我決定用倍數的即時書籤來測試.

我用的是虛擬機環境(VirtualBox), cpu 是p4 1.8g, 只配256M記憶體 - 會這樣少實在是因為我這台只有512M而已, 況且只測試Fx3的條件下其實夠跑了. 此外解析度也調到最小的800x600, 除為了節省記憶體外也為了輸出適中的圖片

接下來就看圖說故事了...


這是"乾淨"的Fx3, 之前有先看過靜置幾分鐘的情況, cpu或記憶體大致上都不會有什麼變化


這次要restore的檔案, 是直接拿預設的備份, 裡面先把幾個少少預設書籤砍掉後加入即時書籤, 書籤會放在書籤工具列上的"TEST RSS"資料夾, 共有217個, 比較原始的檔案容量5k至少大了二十幾倍. 書籤來源全都是從國內的新聞網站收集的


這是restore開始後約兩分鐘的情況 - 剛好是資料夾出現的時間, 但事實上完成進度僅一半左右. 這期間不但持續大量使用cpu, I/O同時在持續動作, 記憶體也瞬間大量上升 - 峰值會略衝過200M, 而且在結束前至少會有兩次大幅下降後又上升這樣起伏的情況


經過4分鐘完成, 完成之後記憶體會回降, 不過還是比乾淨狀態下大了約一倍.





刻意連續放四張, 是restore完後將Fx3重開, 再靜置看看的情況. 這種數量的即時書籤之下, 最慢兩分鐘最快一分鐘內就會發生一次動作(應該是檢查和更新資料吧, 這段在下沒能觀察得很清楚), 每次動作大概都在數秒鐘內完成, 期間cpu用量不至於像restore時幾乎滿載, 大致上只會在瞬間衝到一半左右. 此外, 每完成一次動作記憶體都會小幅上升, 最少2M最大接近5M左右


現在是準備要將所有即時書籤刪除


這個動作至少也花了三分鐘才完成, 而且還會額外花掉十幾M的記憶體(跟restore後一樣, 降不太回來), 這情況其實也證實到之前有人反應說在刪除 - 也就是大量變動書籤時會非常慢. 在restore跟現在這種情況下, Fx3應該都花掉相當多資源處理資料庫更新這一類的動作.

----

這裡我想強調一下, 這次故意用這麼大量的書籤來測, 不是要突顯問題的嚴重性, 而是顧慮到即使各人環境的不同, 仍有可能在用較少的書籤下結果差距太有限直到很難觀察出來. 不過, 有時只看圖片還是沒有實際操作時的感覺來的真切, 事實上, Firefox3這個問題確實很明顯地發生的機率太大, 以致於相較於Fx2版下, 有大量書籤的使用者感覺會特別差的緣故.

就個人的感覺, Fx3這個問題可以算是一個明顯被"延宕"的產品瑕疵, 之所以這樣說, 是因為在測試版期間(RC2之前, 主要是linux版的bug, 但不是針對Live Bookmark的), mozilla就已經針對過bug問題嘗試找出根源一次解決的辦法.

在bugzilla看一些人公開的對話裡, 就有幾個結論是指向sqlite的, Firefox用的sqlite版本其實很舊, windows版的sqlite版本3.5.4.1是去年底發行的, Linux版更不用說, 目前我的套件版本指到3.4.2.2. 更orz的是, 現在不是把它換到最新版就能搞定了, 新的版本雖然有修到幾個I/O問題, 但顯然對Fx3並沒有任何幫助, 而且事實也證明就算sqlite本身ok, Fx3也得同時調整一些程式才行(所以才會有社群版率先放上改過後的js檔了, 但以目前的情況來說當然不能算根本而完整的解決這缺陷)

所以測試版期間那個bug解決途中, 才會有人說出"寄望往後的新版sqlite能幫得到幫", 猜想大概是等3.6吧? 不管怎麼說, 當初問題並沒有被完善的解決, 但是"交貨"在即, 測試版的bug也只能這樣先"結案"了...

只是沒想到現在正式版出爐後相關問題就一次爆開... 在這個bug report裡都有人開始用三字經開罵了(唉), 雖然官方一直沒能公開的承認採用sqlite的作法是導致Firefox效能異常問題不但存在已久(Fx2就開始在用, 到Fx3大幅擴展到places應用), 到今日程度還可能開始惡化的共同原因, 但很顯然使用者可能早已察覺有點不對勁了, 會把問題拖到這麼久的程度很難不讓人想像是不是設計上的錯誤導致後來沒有足夠的技術或資源可以解決.

說真的, 在我眼裡這是繼Fx2(1.5) memory leak議題之後, Fx3令人最覺得遺憾的一件事, 無論現在有多少人可以靠自力救濟的方式繼續用下去, 都一樣註定相當一段時間不能好好"完整而正常"的設定與使用Fx3 - 今天把即時書籤移走, 下次會不會又有什麼東西不定時清理不行. 據他們的預期, Fx3.1也許有機會修正這個缺陷, 不過相對的, 等待的時間恐怕也會很久(年底?);

目前能做的不外乎盡量限制本地書籤的數量, 即時書籤的部份完全讓其他的RSS閱讀器來接手, 如果對安全有把握的話乾脆全部改成線上存放吧.

最後, 這次有人會因為無法忍受這個糟糕的缺陷而"跳槽", 個人完全無話可說, 只希望mozilla能好好正視並檢討一下這不該有的錯誤, 並且在最快的時間內提出根本的方案.


ps:以上部份的內容純屬個人的看法, 如果有任何說法等錯誤請見諒並給予指教.

_________________
終結苦難!萬敗球隊雪恥!08年大聯盟世界大賽冠軍!
當粉絲不算什麼, 當費絲(Phans)才是了不起!

或許我該慶幸 seamonkey 不支援 rss，所以我沒有在 bookmark 塞 rss 的習慣。

_________________
想讓 Internet Explorer 當掉嗎?

「方法一」 - 被 google 檔掉的樣子，開不起來

「方法二」

Fx3的live bookmark處理效能太差了，
導致經常無回應好久，甚至直接當機關閉，
真希望這個問題能快點解決，不要等太久

我還有個問題，因為我通常不會開測邊欄來顯示書籤，都是從最上面的工具列->書籤，去選擇書籤，可是現在發生一個問題～

本來滑鼠點到哪，就會自動的打該開目錄，顯示裡面的書籤，可是開一兩層後，常常會自動離開書籤，回到頁面，要不就是選沒幾個就不見了，又或者是明明我已經停在某書籤上，也按滑鼠右鍵打算開在新分頁上，結果滑鼠點開到新分頁卻無動作，但是其他選項又可以動作～

我確定滑鼠沒問題，因為之前在2.0版也沒發生這樣的狀況，可是到了3.0確有這種狀況發生。

建議需要讀 RSS 的，還是裝 Sage 來用吧！For Fx 3 的 1.4.2 版蠻好用的。

_________________
:::: 簽名檔分隔線 ::::
免費好用又自由的輸入法 gcin Windows | 勸大家以後不要再買 ATI

大家別忘了 Firefox 的好搭檔 → Thunderbird (雖然我覺得 Firefox 好像有意遺棄它的感覺....為什麼 RSS 程式清單裡沒有 Thunderbird ...＝　＝)
這也是一個可行的方案，就算你沒有在用收件軟體收信，也是有很多人把 Thunderbird 純粹當 RSS Reader 在用的。

用 Sage 可以避開問題嗎？

_________________
- Wayne

之前 2.0.0.X 的時候，Sage 存的書籤不是 Live Bookmark，所以不會隨 Live Bookmark 更新，但現在 3.0 書籤系統大改，我不確定現在架構是如何。但我剛剛看 Sage 1.4.2 在更新的時候，是一條一條慢慢更新，cpu 沒有飆，到目前為止尚未遇到問題。yuoo2k 之前改的 Sage CE 也不錯用。

_________________
:::: 簽名檔分隔線 ::::
免費好用又自由的輸入法 gcin Windows | 勸大家以後不要再買 ATI

想問一下喔~ 就是用 Sage 的話可以把它丟到書籤工具列去那樣用嗎？ 我記得我以前用好像不行，用 Live Bookmark 的人應該也有不少人這樣做的吧？

_________________
- Wayne

難怪有次我為了尋找解決某個問題 用乾淨的配置打開Firefox3沒有異常 但是剛導入書籤後就出現問題了
sqlite這問題很讓人發狂耶 我有點懷疑Firefox3到底能吸引多少新用戶....

另: 在我這linux版的Firefox3(Ubuntu)用得還是蠻順蠻穩定的
windows版的Firefox3(XP)就問題不少了 有時候真想掀桌

如果你是指把 RSS 鏈結存在書籤工具列的話
以前的 Sage 可以，Sage CE 也可以，現在 For Fx3 的 Sage 1.4.2 不行 (For Fx3 的 Sage CE 仍然可以！)
但如果你是指除了將 RSS 鏈結存在書籤工具列，還要顯示 RSS 內的文章標題的話，那 sage 是做不到的。

_________________
:::: 簽名檔分隔線 ::::
免費好用又自由的輸入法 gcin Windows | 勸大家以後不要再買 ATI

不好意思經過一整天的昏厥...(反正當蝙蝠定了XD)

吃完飯後想到的第一件事, 就是把我的profile打開來看 - 不是測試用的而是真正在用的Linux版, 列出我的sqlite檔

.(大小/bytes)
. 7168 content-prefs.sqlite
. 162816 cookies.sqlite
. 2048 downloads.sqlite
. 5120 dta_queue.sqlite
. 23552 formhistory.sqlite
. 2048 permissions.sqlite
. 7950336 places.sqlite
. 2048 search.sqlite
. 3452928 urlclassifier3.sqlite
. 2048 webappsstore.sqlite


不意外的places得冠軍orz(科科), 另外算是我的疏忽吧, safebrosing的兩個選項我有一個沒關, 所以urlclassifier3才會長到3M - 不過要是兩個都開, 用一個月下來肯定十倍都不只

既然明白Fx3的很多功能會跟sqlite牽扯上關係, 我就要開始著手去好好"整頓"這個 - 不是要做到矯枉過正把檔案砍光光, 其實砍了還是自己會長回來(好像木馬XD), 重點其實就是在最低功能的需求下, 要讓sqlite的利用率最小化, 我盡量從最簡單的設定方式著手就可以了

第一個做的.... 其實還是砍檔案:twisted: 把urlclassifier3.sqlite這個檔先直接砍掉, 然後去把那忘記關的safebrowsing給關上
畢竟這個東西完全不牽涉到必須保留的資料, 所以大可以直接砍檔效果最好(指重建之後的檔案可以保持最小)

接著就順便去檢查一下有什麼可能是該設的.
- 我所知有限, 說不定有的沒效. 這部份其實希望能有大大再發掘看看.

> 重翻一次書籤, 發現還保留四五個RSS, 全砍掉
> "歷史紀錄"改成只有一週(預設的長達40天...)
> 保留下載紀錄也關掉
> 當然"有害網站"跟"偽造網頁"這兩個也關掉
> 記住網站密碼 - 這個其實看個人方不方便吧, 基本上我保留
> 快取資料 - 預設是50M. 這項我其實不是很確定是否跟sqlite有多大關連, 不過我再看看在不會影響速度之下應設的最小值是多少吧
> 套件會有用sqlite紀錄的設定一律關掉(像dta我一開始就是關的)


最後, 我去找回SQLite Manager套件再裝起來用. 當初第一次用它只是想看看urlclassifier3到底是怎麼給我生出那麼多東西, 後來用砍的之後想想不會再用到所以拆了. 從這次開始我想它應該會列在我的必用套件清單吧

雖然Win跟Linux都有檢視sqlite的工具程式, 不過只有這個套件不但小巧而且是唯一設計來專門檢視跟處理Firefox profile資料庫檔案的, 如果需要處理有關sqlite議題的話個人是大力推薦這個套件
(不過有點可惜的是目前為止尚未正體中文化...)

用它去compact 較大的 database後重開Fx3, 看看最後的成果吧


.(大小/bytes) *代表有效的, 另外其他持平的應該已經是最小不可能再縮減的
- 7168 content-prefs.sqlite
* 102400 cookies.sqlite
- 2048 downloads.sqlite
- 5120 dta_queue.sqlite
- 23552 formhistory.sqlite
- 2048 permissions.sqlite
* 4657152 places.sqlite
- 2048 search.sqlite
* 32768 urlclassifier3.sqlite
- 2048 webappsstore.sqlite


就這樣, 希望他們不要再像大樹一樣長高囉

_________________
終結苦難!萬敗球隊雪恥!08年大聯盟世界大賽冠軍!
當粉絲不算什麼, 當費絲(Phans)才是了不起!

看來應該就是這方面的問題了....
感謝Tenki的熱心測試

另外我想說，如果IO裝置很慢，就算Live Bookmark數量很少也會感覺得出來....
我只覺得它在這方面的決策真的很失敗
我想我在Windows上還是繼續用FX2吧....
我的記憶體夠大，不怕leak
但是我很討厭delay

_________________
以下為簽名檔
半荒廢日誌....

Foolproof Project:
KomiX 漫畫瀏覽
Khopper 音樂轉檔

就算你百分之一百認定某人是渣滓中的渣滓，請仍然展示你的冷靜、體諒、尊重。

這是我的 SQLite 檔大小：

* content-prefs.sqlite 7k
* cookies.sqlite 9k
* downloads.sqlite 11k
* formhistory.sqlite 46k
* permissions.sqlite 2k
* places.sqlite 1.8M
* search.sqlite 5k
* urlclassifier3.sqlite 32k

_________________
- Wayne

我在把 Firefox 移到 Ramdisk 執行時然想到一個問題喔，就是若只是把 Cache 和 sqlite 檔用軟連結引導到 Ramdisk 裡會不會沒有效果啊？

_________________
- Wayne

只希望問題得到釐清就好, 這樣至少大家心理多少舒坦一些吧(老實說, 其實我希望我的測試是錯的... 囧")

不過正好我忘記提到我的硬碟

事實上, 我在使用Linux電腦 - 也就是這次測試開虛擬機的, 不只是cpu很舊, 硬碟更不怎麼樣(最近感覺操太兇可能出狀況). 系統用的是Seagate 20G ST320423A(用兩顆, 切開/usr), 虛擬機檔案所在的home目錄用的是Maxtor 40G 6E040L0. 全都是二手的老舊硬碟.

以這樣的測試其實應對Fx3有一點不公平, 低傳輸率裝置加上虛擬機環境會對效能有加成影響. 唯一"彌補"的大概就是無干擾的乾淨profile吧(有套件的情況下不但更糟也把情況弄複雜). 但相對的看結果其實事後感覺還比想像(預期)中的好一點, 畢竟沒多少人用這麼大量的書籤, 在現實情況下程度那些現象也許會再小一點, 此外更不用說有的是替代方案可以用, 這樣一來其實這議題可以當作不存在了.

... 這不是在幫mozilla說話, 個人只是認為, 面對這種效能問題, 其實對各人不同的條件就會有不一樣的選擇方向, 以我的情況來說, 我一直就在打算把我的Ubuntu移到另台配備更好的電腦上 (可以說正式扶正它以向貫徹純Linux的目標邁進嗎XD), 一次把cpu/ram/硬碟通通提昇. 再怎麼說還是要回歸使用者感覺這一點上, 無論個人的"敏銳度"差異有多大. 對我而言, 提昇硬體這種更直接的方式才有把握能讓我把不該有的制限感覺得到完全的紓解.

不過話說回來, 這裡我也想對可攜版本提出個小小看法(雖然我沒去用這個), 我想Fx3的設計也許本來就不適合用在可攜版上, 除非改造的人有辦法把places系統整個切掉套回舊式的, 只不過這應該難度很高就是.

最後還是要說聲遺憾啦, 不過就算是在Fx2裡我還是建議最好能去看看sqlite檔案 - 前面說的bug就是橫跨2.0跟3.0的, 所以就算不會用到places, 最好還是偶爾注意這些檔案的情況.




... 大大的places實在夠小啦XD
- 其實幾M以內我認為也許就可完全避免效能問題了

_________________
終結苦難!萬敗球隊雪恥!08年大聯盟世界大賽冠軍!
當粉絲不算什麼, 當費絲(Phans)才是了不起!