Home » 2008 » November

講話沒聲音了...

抱怨一下,這次感冒 (?) 的後遺症超嚴重,今天睡醒起來居然沒聲音了,似乎該去找醫生看一看...

Update:果然是發炎了,不過還加上出血 =_=

MySQL 5.1.30 (5.1 的第一個 GA version)

建議觀望兩個版本 XD

MySQL 5.1 正式釋出了,比預訂的 12/6 早了一個多禮拜。目前 dev.mysql.com 處於被 DDoS 的狀態,不太容易連上,需要的人應該儘量到最近的 mirror site 找。

這個版本不建議大家先上的原因是,我們 (PIXNET) 自己測試 5.1.29-rc 時發現在大量的 request 時,有時候會 connect fail,而這個 bug 在 5.1.30 的 changelog 裡沒看到相關的訊息。一種解法是在 application 層 retry,不過這種方法實在是不太舒服,還是等一陣子再說... XD

MySQL Community 版本

MySQL ABSun 買走後,MySQL 官方宣佈了一些事情,到目前看起來,最大的改變是把 MySQL 的版本控制軟體從 BitKeeper (close source) 轉移到 Bazaar

版本控制軟體變成 open source 使得 source code 的取得以及追蹤變容易了,於是有許多人就自己建立 branch 發展,相當熱鬧。(因為有版本控制,容易與官方的 branch cross-merge,有些人會在 community 版互相 merge)

主要幾個有名的 patch vendor 包括:

遇到奇怪的 bug,或是多 CPU 效能瓶頸時,試看看這些 community version 會是不錯的方向。

Index 很重要...

還好即時發現,差點撐不過今天晚上 -_-

簡單先找出最吃 CPU resource 的 SQL query,針對他的 WHERE 條件加上適當的 Index 後:

這樣就爭取到調整的時間了...

Amazon CloudFront (Amazon CDN)

沒想到 Amazon 這麼快就推出 CDN 服務了:Amazon CloudFront

先說價錢的部份。就這陣子接觸 CDN 的狀況來說 (大約接觸了六七家),zero-commitment 這個價錢相當驚人。CloudFront 與一般的 CDN 的價錢算法不太一樣,一般都是大致上告知各地區的用量,CDN company 會給你一個 package,這個 package 包括一定程度的 commitment,以及超過 commitment 時的價錢。CloudFront 沒有 commitment (這是預期的,因為之前他們宣佈要開發 CDN service 時就有說明這件事情),另外依照不同地區的流量,收不同費用,與其他家的算法相比,這樣的確很有競爭性。實際上,Amazon 所放的機房似乎有談到比較好的價錢,Price 的部份可以看到大約是 USD$0.2/GB。

就技術面來說,CloudFront 全球有十四個點,亞洲地區是在東京與香港,這點與一般的 CDN service 差不多,這兩個點是亞洲區交換的重心,基本上都會在這兩個地區架點。

第一步是看 DNS 的架構,DNS 是 Anycast-based,從台灣各 ISP 連過去,看起來都是到香港的 DNS server,至於封包怎麼到香港,又怎麼樣回台灣,這又是另外一回事情了...

再來是看 latency,這個部份通常會配合 traceroute 測試 (觀察每個點的狀況)。traceroute 的目的地可以用 Amazon 自己提供的 d1nqj4pxyrfw2.cloudfront.net,或是自己申請的 domain 測試,會發現從 HiNet 過去的 latency 不低 (用幾個不同的地區 ADSL 測試),TFN 似乎與香港機房的 ISP 有 peering,所以數字很漂亮,而 KBT 是走美國再到香港機房。

這是一些數據:

HiNet ADSL:

 3  tp-s2-c76r5.router.hinet.net (168.95.82.202)  34.846 ms  33.004 ms  36.084 ms
 4  tp-crs11.router.hinet.net (220.128.2.230)  33.595 ms
    tp-crs11.router.hinet.net (220.128.3.142)  34.207 ms
    tp-crs11.router.hinet.net (220.128.1.230)  34.757 ms
 5  r03-s2.tp.hinet.net (220.128.2.190)  31.899 ms
    r03-s2.tp.hinet.net (220.128.1.178)  34.508 ms
    r03-s2.tp.hinet.net (220.128.2.190)  32.021 ms
 6  tp-s2-l233-81.router.hinet.net (211.72.233.81)  196.329 ms  194.428 ms  194.215 ms
 7  po-1.a05.newthk01.hk.ra.gin.ntt.net (203.131.240.238)  193.144 ms  194.112 ms  198.367 ms
 8  203.131.243.162 (203.131.243.162)  209.246 ms  208.731 ms  204.362 ms
 9  216.137.55.35 (216.137.55.35)  193.126 ms  196.422 ms  194.614 ms

TFN:

 3  60-199-255-113.static.tfn.net.tw (60.199.255.113)  0.240 ms  0.229 ms  0.240 ms
 4  60-199-6-125.static.tfn.net.tw (60.199.6.125)  0.364 ms  0.353 ms  0.365 ms
 5  60-199-6-2.static.tfn.net.tw (60.199.6.2)  0.365 ms  0.353 ms  0.366 ms
 6  60-199-6-222.static.tfn.net.tw (60.199.6.222)  11.607 ms  0.602 ms  0.615 ms
 7  61.58.33.145 (61.58.33.145)  0.613 ms
    61.58.33.173 (61.58.33.173)  15.341 ms
    61.58.33.189 (61.58.33.189)  0.718 ms
 8  xe-0-0-0.r20.taiptw01.tw.bb.gin.ntt.net (129.250.16.161)  0.846 ms  0.721 ms  0.862 ms
 9  as-0.r20.tokyjp01.jp.bb.gin.ntt.net (129.250.4.217)  35.342 ms  35.825 ms
    ge-0-3-0.r01.taiptw01.tw.bb.gin.ntt.net (129.250.3.174)  36.840 ms
10  as-1.r20.newthk01.hk.bb.gin.ntt.net (129.250.2.110)  57.059 ms
    as-0.r02.newthk01.hk.bb.gin.ntt.net (129.250.4.205)  34.951 ms  23.712 ms
11  ae-5.r21.newthk01.hk.bb.gin.ntt.net (129.250.2.81)  70.317 ms
    ae-4.r21.newthk01.hk.bb.gin.ntt.net (129.250.5.65)  23.455 ms
    ae-5.r21.newthk01.hk.bb.gin.ntt.net (129.250.2.81)  58.428 ms
12  po-1.a05.newthk01.hk.ra.gin.ntt.net (203.131.240.238)  70.435 ms  23.338 ms  70.447 ms
13  203.131.243.162 (203.131.243.162)  23.599 ms  23.464 ms  21.229 ms
14  216.137.55.28 (216.137.55.28)  23.847 ms  70.680 ms  70.573 ms

KBT:

 3  58.86-0-host249.kbtelecom.net.tw (58.86.0.249)  0.233 ms  0.228 ms  0.360 ms
 4  TWGATE-VLAN-859.IX.kbtelecom.net (203.187.9.205)  0.611 ms  0.481 ms  0.734 ms
 5  TWGATE-C65-10G2-1-TPNOC1.IX.kbtelecom.net (203.187.6.202)  0.732 ms  0.730 ms  0.860 ms
 6  PAIX-T76-G2-1-TWGATE.IX.kbtelecom.net (203.187.3.74)  137.412 ms  137.385 ms  137.785 ms
 7  GigabitEthernet2-0.GW4.PAO1.ALTER.NET (157.130.214.173)  137.515 ms  137.397 ms  137.512 ms
 8  124.ATM3-0.XR2.PAO1.ALTER.NET (152.63.49.230)  137.657 ms  137.602 ms  137.764 ms
 9  0.so-5-2-0.XT1.SCL2.ALTER.NET (152.63.54.134)  137.909 ms  137.804 ms  137.842 ms
10  204.255.169.182 (204.255.169.182)  139.285 ms  139.353 ms  139.509 ms
11  ae-1.r20.plalca01.us.bb.gin.ntt.net (129.250.5.117)  138.799 ms  138.586 ms  138.407 ms
12  ae-1.r21.snjsca04.us.bb.gin.ntt.net (129.250.4.119)  140.262 ms  140.144 ms  140.144 ms
13  as-1.r21.osakjp01.jp.bb.gin.ntt.net (129.250.3.198)  159.242 ms  159.132 ms  159.254 ms
14  ae-4.r20.osakjp01.jp.bb.gin.ntt.net (129.250.4.57)  159.143 ms  159.248 ms  159.252 ms
15  as-2.r21.newthk01.hk.bb.gin.ntt.net (129.250.4.46)  201.124 ms  203.150 ms  201.114 ms
16  po-1.a05.newthk01.hk.ra.gin.ntt.net (203.131.240.238)  202.980 ms  220.093 ms  202.851 ms
17  203.131.243.162 (203.131.243.162)  201.847 ms  201.868 ms  200.233 ms
18  216.137.55.227 (216.137.55.227)  201.604 ms  201.568 ms  201.477 ms

以亞洲區的情況來說,其實也不能說差到哪裡,因為亞洲區各地區的網路環境本來就比較複雜,很多 ISP 拉到日本或香港的是談 peering 而非 transit,如果放的 ISP 不是大戶就會像 HiNet 這樣。

台固 (TFN) 看起來是買日本 NTT transit 代替美國電路 (這點在 TWNIC 的資料可以推估出來),所以數字就好看很多 (不過還是跑到香港 XD)

離開亞洲,把測試環境拉到美國本土,情況就不太能讓人接受了。如果以美國的伺服器測試,以西岸 Cogent Co 的伺服器連上面所提到的 hostname,發現居然被導到東岸的機房... (喂喂)

Cogent Co:

 3  te8-4.ccr02.sjc01.atlas.cogentco.com (154.54.6.69)  0.613 ms
    te8-4.mpd01.sjc01.atlas.cogentco.com (154.54.6.73)  0.603 ms
    te8-4.ccr02.sjc01.atlas.cogentco.com (154.54.6.69)  0.603 ms
 4  te7-4.mpd01.sjc03.atlas.cogentco.com (154.54.6.234)  1.598 ms
    te4-2.mpd01.sjc03.atlas.cogentco.com (154.54.6.106)  1.224 ms
    te7-4.mpd01.sjc03.atlas.cogentco.com (154.54.6.234)  1.226 ms
 5  te-3-3.car3.SanJose1.Level3.net (4.68.110.137)  1.099 ms  1.095 ms  1.110 ms
 6  vlan99.csw4.SanJose1.Level3.net (4.68.18.254)  3.240 ms  6.099 ms  1.740 ms
 7  ae-94-94.ebr4.SanJose1.Level3.net (4.69.134.253)  3.738 ms  7.825 ms  2.486 ms
 8  ae-2.ebr4.NewYork1.Level3.net (4.69.135.186)  73.826 ms  73.220 ms  73.325 ms
 9  ae-74-74.csw2.NewYork1.Level3.net (4.69.134.118)  73.193 ms  74.808 ms  72.824 ms
10  ae-71-71.ebr1.NewYork1.Level3.net (4.69.134.69)  73.321 ms  73.189 ms  73.525 ms
11  ae-2-2.ebr1.Newark1.Level3.net (4.69.132.98)  78.324 ms  76.045 ms  74.122 ms
12  ae-12-53.car2.Newark1.Level3.net (4.68.99.70)  74.779 ms
    ae-12-55.car2.Newark1.Level3.net (4.68.99.134)  73.799 ms
    ae-12-51.car2.Newark1.Level3.net (4.68.99.6)  88.805 ms
13  AMAZONCOM.car2.Newark1.Level3.net (4.79.190.182)  74.351 ms  73.560 ms  73.697 ms
14  216.137.41.112 (216.137.41.112)  74.697 ms  74.173 ms  74.696 ms

網路層面看完後,再來是看 Web server 的 performance,這點 Amazon 提供的服務慘不忍睹,實際以 http://d1nqj4pxyrfw2.cloudfront.net/cfcurl.pl 抓檔案測試發現,居然沒支援 gzip:

x-amz-id-2: gS6hQRsamtiyGdmpkpaHlt0mFE0tcBrzrV5QuJm4f5ObZX91IeLasylUvNj1h4B+
x-amz-request-id: BA60E611E0CBD3B9
Date: Tue, 18 Nov 2008 17:51:10 GMT
x-amz-meta-s3fox-filesize: 7482
x-amz-meta-s3fox-modifiedtime: 1225495075000
Last-Modified: Mon, 17 Nov 2008 18:54:09 GMT
Etag: "42c51d029cc4a9f2a3f06a494af4f020"
Content-Type: application/x-unknown-content-type
Content-Length: 7482
Server: AmazonS3
Age: 12848
X-Cache: RefreshHit from cloudfront
Via: 1.0 0904298d6eb16ce0af632faa366b71c4.cloudfront.net:11180 (CloudFront),
     1.0 03b371403ea88af54def5cba2800dc5f.cloudfront.net:11180 (CloudFront)

待續。

Ruby 1.8.7 (以及 1.9) 的 RSS::Maker

中地雷了... 測試程式在 http://gist.github.com/25425 這裡。

Ruby 1.8.6 (FreeBSD 7) 上面測試會輸出 RSS 2.0,但在 Ruby 1.8.7 (Ubuntu 8.10) 上則會輸出空字串。xdite 拿了同樣的程式去 1.9.0 上測試也是出現空字串。

freenode 的 ruby-lang 上提了這個問題,結果有人說 1.8.7 弄爛了太多東西,他不會感到意外 XDDD

Anyway,這個功能到還沒有那麼急迫要修好,所以這陣子大概是不會好的吧... (可以自己寫 generator,RSS 2.0 的 feed 並不難寫)

Firefox 3.1 的 JIT

Minefield nightly build 版本的人心臟總是要大顆一點...

我目前的版本是 20081111032821 (User-Agent 是 Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b2pre) Gecko/20081111 Minefield/3.1b2pre),剛剛發現黑心人形の部屋是個 reproducible crashing page,一步一步測試,發現是 javascript.options.jit.content 造成的問題,設定成 false 就正常了。

用 Minefield 的人如果有一直 crash 的困擾,可以試著把 jit 關掉,可能會有幫助。

在 FreeBSD 上安裝 Merb 1.0

上一篇提到 FreeBSD 上暫時因為 RubyGems 版本問題,沒辦法裝 Merb 1.0,我決定自己來惡搞...

一開始是想裝 Ruby 1.9,據說內建 RubyGems,但裝上去後發現內建的版本是 RubyGems 1.0.1,比 FreeBSD Ports 的還舊,還是自己動手把 Ports 裡的 RubyGems 升級好了...

要將 FreeBSD Ports 裡的 RubyGems 更新到 1.3.1,最麻煩的是要生出 pkg-plist,這點由 ports maintainer jw at innerewut.de 做的差不多了,他寫了 x-generate-plist 會幫你產生 pkg-plist,所以很容易就把 pkg-plist 做完然後 send-pr。(參考 ports/128731: [PATCH] devel/ruby-gems: update to 1.3.1,裡面有 patch file)

升級完成後就是要裝 Merb 了...

我的打算是等 clsung 更新 www/rubygem-merb 前都先完全用 gem 管理 RubyGems 套件,而不透過 Ports 管理 (他是這個 ports 的 maintainer)。所以接下來就是跑 sudo gem install merb

跑到一半會喊 sqlite3.h 不存在,先把 databases/sqlite3 裝進系統,再用 sudo gem install do_sqlite3 --with-sqlite3-dir=/usr/local 把 do_sqlite3 裝進去。接著繼續跑 sudo gem install merb 把剩下的套件都裝完。

然後裝一些一定會用到的東西,像是對 MySQL 的支援套件:sudo gem install do_mysql

大致上就是這樣...

Update:還少了 sudo gem install json,剛剛要 merb-gen app project 的時候發現會說少了 Json::Iconv 而不能跑 XD

Update:跑 merb 的時候發現還少了 DataMapper,所以要再裝 sudo gem install datamapper

Update:結果還是一直喊找不到 dm-types...

Update:還少了 sudo gem install mongrel

Update:dm-types 的問題可以在這篇回報看到一個 patch,這個 patch 預定在 1.0.1 會修正,在還沒修正前需要自己更新:I have dm-types gem installed but still get - FATAL: The gem dm-types (= 0.9.7, runtime), [] was not found

Archives