[PHP] optimization for shortening the API calls

最近為了降低API calls,所以在Shark內加入了一個Method可以讓使用者自行依自己的需要來延遲整個程式的執行:

http://gist.github.com/309735.js?file=gistfile1.php

參數是所需延遲的秒數,0就是不延遲。

雖然這裡沒有什麼技術上的難度,講白點就是丟給sleep()去跑而已,但是我想討論的是它所造成的影響。先看一下下面的統計圖:



2/14和2/15是平常的情況,所謂的平常就是用無窮迴圈去跑Bot,只算「登入」和「基本檢查」這幾個動作,而已,就會拉高整個呼叫API的情況,非常的跨張,這就是為什麼北極冰山快融化完的關係,因為大家只要寄個信給Plurk官方就可以突破原先50000次的限制,要怎麼用就怎麼用,非常爽快。

但是再看看2/18和2/19的時候,這是我讓Shark加入了延遲的動作,我記得是設3秒鐘,夠誇張吧,直接下降到23000的次數了,你連寫信去Plurk的動作都省下來了,還有27000次讓你做別的事情,這樣不是很開心嗎!? (大約下降了78%..),真是從小處著手,就有很大的改變呢…(忘了說,使用者很難感受到機器人回覆plurks的時間差,一樣很快)

所以麻煩大家不要一直用「while(true)」或是「for(;;)」這樣子的東西,要用的話至少也要加個中止條件或是延遲,不僅可以減少系統資源的開銷,還可以保護北極熊不會因此死光…

[Research] Dartboard Statistics Method

我的我

共有16筆資料

2.2(-1.1)

4.1(+0.8)

3.5(+0.2)

4.5(+1.2)

3.4(+0.1)

1.6(-1.7)

3.1(-0.2)

3.2(-0.1)

3.2(-0.1)

3.7(+0.4)

3.0(-0.3)

2.6(-0.7)

3.8(+0.5)

3.1(-0.2)

4.7(+1.4)

3.7(+0.4)

平均≒3.3

說明:

圖上的每個間距是0.5(看統計者要統計到多詳細),而中間那條線代表平均值(在本例為3.343)而藍色部分代表的是大於平均值的資料,紅色部分代表的是小於平均值的資料,然後依照離均差的大小來決定資料點是落在哪個圓內,之後依照圓內點的數目比上所有點的數目求出分佈機率(ex:最小圓有10個點,全部有16個點,其分佈機率為62.5%)





如果我們以平面的角度來看的話,會發現他的分佈情況是呈現在一個呈現兩色的二維鏢靶上,可以很明顯的看出整體資料的離均情況。在這邊要特別討論一下這個圖的優點,因為我認為就算是一些不常出現的極值,還是整體資料的一部分,所以如果為了建出理論的完美模型而拾棄那些極值,反而是和現實生活不合的情況。因此我是以離均的大小來建構出這個圖,所以就算是少數極值也只會分配在最外圍的圓上,不會對整體架構產生太大的影響。





統計方法命名:

Dartboard Statistics Method – 鏢靶統計方法