各位應該發現，最近的計數器比之前快非常多，這需要感謝amy與艾瑪大大的網誌使用我的計數器，讓我得到寶貴的數據，才能具以重整計數器的架構。
即使效能提昇非常多，但是基本的計數耗時是免不了的，我的計數器是使用bbclone，是一種純檔案計數器，修改後的計數器在每次網頁開啟時，會進行兩個動作，計數與統計，計數約要花0.07秒，統計約要花0.7秒，因此一次計數加上一些基本耗時，約要0.9秒。
此外，計數器的數字是需要在統計完才能取得並顯示在網頁上，如果只計數，計數器的數字不會反映實際的人次或人數，必須等到統計後，才能真實地反映訪客人次、訪客人數或線上人數，本文的重點也在此，要如何在效能與實際人次與人數間做取捨。
先前每一篇文章被開啟時，除了這個文章會被計數與統計外，網誌的首頁也同樣需要計數與統計，因此約要2秒鐘，聰明的您可能發現，網誌的首頁將會成為瓶頸，也就是越多人看文章，網誌首頁都要進行加總的統計與分析，同時太多人看時，就需要排隊等著計數，也拖慢了文章網頁的開啟速度，離譜一點可能要等上7或8秒。
為了排除這個問題，目前排除了首頁的統計，只對首頁計數不統計，因此文章只需要1秒鐘就能開啟，不過首頁在開啟時，就要處理所有累積的統計，以及本次首頁的計數與統計。例如，首頁開啟前有訪客看了10篇文章，那麼需要0.7*10秒的統計，加上本次0.7+0.07的計數與統計，因此約要耗時8秒。首頁拖那麼慢是大家不能忍受的，這也是為什麼除了我目前努力改進的計數器外，其他的計數器都沒有提供單篇文章計數與首頁的加總計數的主要原因，這裏的計數包含計數與統計。
如果只計數不統計就能反映出實際的人數與人次，上述的問題就能獲得根本性的解決，這是我下一版計數器的架構，不過統計上的痛苦時耗還是無法避免，這可以交由背景的批次作業來達成，就工作量而言，主機一樣是要做那麼多事，但是網頁的開啟完全不會拖慢。
但就目前而言，在即時與批次作業的取捨上，產生了三種取捨情形，描述如下：
1.文章與首頁都計數不統計，統計全交由批次作業排程處理：好處是完全不拖慢網頁，只需要0.1秒就能夠顯示，但是在批次作業處理到該文章或首頁的計數器前，數字都不會更新。以目前而言，批次作業最快是一分鐘處理一次，因此有一分鐘的誤差，當然如果排程為兩分鐘，就會有兩分鐘以上的誤差，依此類推，時間上的取捨，完全要看計數器的流量而定，但最快就是一分鐘，這是系統的限制。
2.文章與首頁都計數與統計：這個問題在上面的描述中已談過，文章的開啟會被拖到很慢，首頁的開啟最理想的狀況
約1秒，因為加總計數與統計已經分攤在每次文章的開啟上，但是這是建立在首頁開啟的同時並沒有很多其他的文章被開啟中，如果有，要等所有文章的加總計數與統計都完成後，首頁的計數與統計才能被完成，簡單講，就是同時開啟的文章都處理完之前，首頁只有等待。
3.文章計數與統計，但是首頁只計數不統計，首頁的統計交由批次作業排程處理：這樣每一篇文章都只要1秒就能看到實際的人次與人數，但是首頁也算是一個文章，因此首頁開啟時，還是會去處理之前的所有加總計數，可能需要上述的許多秒，首頁的開啟一樣會被拖到很慢。
除了第1點外，第2點與第3點都能即時地反映出實際的人次與人數，第1點相較於其他兩點在速度上是極快，但是有時間上的誤差，第2點會讓首頁的開啟拖到很慢，而第三點則很平均，但是最少要耗2秒。
就計數器要反映出實際的人數與人次的考量上，對於每天人次沒有超過千次的人而言，第2點或第3點都沒多大差別。對於每天有數千次人次的網誌而言，第3點可能比較優。不過如果訪客都直接去看首頁，鮮少去看文章，那第2點與第3點都沒有多大差別，但是這就不像是網誌，倒像是留言板，基本上完全不考慮。
對每天有上萬或數千人次的網誌而言，訪客造訪的時間常常都集中在一天的某幾個小時，首頁必然會被拖到很慢，因此第1點是唯一的選擇，否則應該是要選第3點，如果2秒鐘或更久可以忍受，只希望能反映即時人次與人數的話。
就另外一個角度來想，如果排程是以一分鐘為間隔，訪客看一篇文章的時間如果超過一分鐘，那麼即不即時就沒有多大影響，在首頁上的數字少一個多一個根本不痛不癢，最重要的是大家並不知道。
基於假設一分鐘必然能夠處理完排程中的所有統計，以阿Q一點的心態，差不多就好的話，第1點應該是最好的選擇，基於以上的討論，相信各位應該不難理解這是最佳的決策。
未來有可能的話，會將上述3點給使用者選擇，不過不是每個人都會看到這文章，也不一定能理解這文章，這樣的選項交給使用者，很可能是拿石頭砸自己的腳，大家都在狀況外。

Trackback URL:
計數器::Comments(0)::Trackback(0) ::Hits(161)