Home » 2008 » July

SimpleCDN

SimpleCDN 是最近看到的一個 service,就實際的情況看起來,他不是真正的 CDN,不過他的價位還算 okay,而且有免費的 15 credits (也就是 USD$15) 可以玩。

SimpleCDN 主要有三種模式,第一種是 Pay Per File,也就是對檔案付一次費用就可以一直下載。第二種是第一種的加強,強調會自動處理抓取檔案並收取費用。第三種是 Reverse Proxy 模式,收費是 0.07 credits/GB。

第三種模式跟 GigaWebAMP 其實很接近,不過 SimpleCDN 的好處在於依照使用的量計費,不像 WebAMP 是每天有固定的量可以讓你用。速度上,從 HiNet 過去幾乎都是透過 PAIXHE 進去,速度還不錯。

不過缺點是價錢比 WebAMP 貴,另外因為要走國際線路,連線速度會比 WebAMP 慢。(不過... 這倒未必 XD)

另外一個不會使用 SimpleCDN 的考量是 Pay Per File 的部份,我覺得這個模式天生就做不起來啊...

頻寬

剛剛翻了一下 TWNIC 的資料發現 HiNet 今年對美國的頻寬加的非常快,第一季 34Gbps,第二季 47Gbps,第三季 57Gbps,不過據說之前是「加了一條就滿一條」,不知道這幾次一直補到底夠不夠用 XD

另外也看得出幾個 ISP 快做不下去了... 頻寬一直減少。

Perl on Google App Engine

Python 是第一個可以在 Google App Engine (GAE) 上執行的程式語言,而下一個很有可能是 Perl

Brad Fitzpatrick 在他的 Blog 上說,他被 GAE team 允許對外公佈「我可以使用 20% 的時間開發 Perl on GAE」:Perl on App Engine

這是 GAE 支援其他程式語言的消息中,第一個被正式公開的。在 Brad Fitzpatrick 的文章裡面有一些藍圖,關於他大概會怎麼做的想法。我們應該可以期待他認真起來的戰鬥力 :p

PS:Brad Fitzpatrick 是 LiveJournal 的創辦人、memcached 的作者、OpenID 的制定人。

WordPress 輸出 Extended RSS (Export) 時的問題

WordPress 有自己的輸出格式可以當作備份檔使用,但輸出的檔案並不是正確的 XML,要做很多處理。

  • 首先他並不保證是 UTF-8 valid,所以要強制轉成 UTF-8 valid。在 PHP 裡可以用 $str = iconv('UTF-8', 'UTF-8', $str); 處理。除此之外,還要把某些特殊字元處理掉:$str = preg_replace('/[\x00-\x08\x0b\x0d-\x1f]/', '', $str);
  • 使用了 <excerpt:encoded> 但卻沒有在開頭定義 xmlns:excerpt。如果需要用到 excerpt:encoded 可以硬轉成 content:excerpt 處理;如果不需要,可以直接拿掉:$str = preg_replace('/<excerpt:encoded>.*?<\/excerpt:encoded>/', '', $str);。
  • wp:meta_value 沒有 encode 過,所以像 & 這類的字元會因為沒有 encode 而造成 XML library 抱怨,如果沒有使用到這些欄位,可以照上面的方法拿掉。如果有用到的話可以拿 htmlspecialchars() 處理後加回去。

把這三件事情處理完後似乎可以解決 WordPress 輸出的 Extended RSS 不合法的問題,用 PHP DOM 也不會跳錯誤訊息了。

其中第三個很明顯是 bug,晚點確認是 WordPress 問題並生出 patch 後得去開 ticket 修正。第二個也很嚴重,但是這個問題已經有人提出來,一直沒解:「WordPress Import Fix for Post Excerpts」,得去 ticket system 上檢查是不是有被提出來討論過。

關於 MySQL 的 --with-fast-mutexes

ports/125616: Add --with-fast-mutexes to databases/mysql51-server」這個 PR 中所提到的 --with-fast-mutex 在 ale@ commit 後,他也順便問是否有變快 (或是變慢)。我回了他一封信,MyISAM 在十個 clients 的模擬測試下有快一些,大約 6%。

不過這是 Super Smack 測試的結果,如果沒有其他比較好的工具,拿來當參考還可以,把結果當作事實就有點偏頗了。我打算複製一份 real data 到其他空機器上,再測試一次看看。

下面這是 Super Smack 測試的結果,最後面的單位是 qps,愈高愈好。

(without fast mutexes)
$ repeat 10 super-smack -D/tmp \
  /usr/local/share/super-smack/select-key.smack \
  10 2000 | grep ...
select_index    40000   0       0       56503.40
select_index    40000   0       0       55638.24
select_index    40000   0       0       55750.29
select_index    40000   0       0       56229.37
select_index    40000   0       0       55770.81
select_index    40000   0       0       56083.44
select_index    40000   0       0       56411.05
select_index    40000   1       0       55156.36
select_index    40000   0       0       56268.21
select_index    40000   0       0       55059.18

(with fast mutexes)
$ repeat 10 super-smack -D/tmp \
  /usr/local/share/super-smack/select-key.smack \
  10 2000 | grep ...
select_index    40000   0       0       59652.25
select_index    40000   0       0       58040.66
select_index    40000   0       0       57937.60
select_index    40000   0       0       58511.95
select_index    40000   0       0       57319.65
select_index    40000   0       0       58308.02
select_index    40000   0       0       58514.35
select_index    40000   0       0       58493.64
select_index    40000   0       0       57937.01
select_index    40000   0       0       59348.24

The first one is 55887 qps (avg), the second one is 58406.3 qps.

Archives