FreeBSD 上的 Gearmand

前陣子提到了「用 C 改寫後的 Gearman」,在當時還是 0.1 版,現在已經 0.2 版了。花了一些時間把他 submit 到 ports tree 裡面,現在可以在 ports 裡的 devel/gearmand 裝起來,然後在 /etc/rc.conf 裡設定:

gearmand_enable="YES"

裝好後預設是聽 port 4730 (IANA 配的位置),並打開 verbose 選項,也就是:

gearmand_flags="-p 4730 -v"

如果要用舊的 port (7003),而且也不想要開 verbose:

gearmand_flags="-p 7003"

這樣就可以了。

FreeBSD 上 PHP5 的 pecl-APC 效能

環境是單顆 E5405 的機器,上面的作業系統是 FreeBSD 7.1,應用程式的部份是 apache 2.2 (worker) + mod_fastcgi 2.4.6 + PHP 5.2.8 + APC 3.0.19。

由於前陣子發現 PHP 在 MP 架構下效能不太好,偶而會有一堆 php-cgi 卡住,用 top 會發現卡在 "lockf" 這個狀態,這時候前端的 L4 switch 會看到 500 Internal Server Error 而把這台機器暫時離線。等到 php-cgi 慢慢消化完,前端的 L4 switch 又會抓到 200。

在 php-cgi 卡住的狀況下試著用 gdb 找原因,當時 backtrace 發現是卡在 APC 裡的 lockf,所以就有一些想法,等有空閒的時候測試。

第一個想法是把 APC 的 lockf (fcntl) 改用 IPC semaphore,這個在 ports 可以調整。重新編完後發現 php-cgi 跑不起來,後來試出來,需要同時打開 mmap support 與 IPC semaphore。

第一張是 webfront-7,跑 mmap + semaphore。第二張是 webfront-8,保持原來的 shm + fcntl (lockf):

效能有「好一點」,但很難觀察出來,實際再加上 webfront-{9,10} 比較後 (都是完全同型的伺服器),看起來 webfront-7 的效能是最好的,所以得觀察當爆量時是否會卡 lockf。

Mosso CloudFiles

很久之前就在關注的服務,與 Amazon Web ServicesS3 + CloudFront 是直接競爭關係。

在很早前就註冊,但一直因為帳號問題而沒測試,當時以為是系統忙碌,懶得寫信去問。這幾天想趁著過年的時候測,發現帳戶還是有問題,所以昨天請他們處理,今天帳號就正常了...

Mosso CloudFiles 的背後是 Rackspace,是一個與 Amazon S3 性質相同的檔案存儲服務,不過與 Amazon S3 不同的是,他的 HTTP 下載部份一定要透過 CDN,不像 Amazon S3 可以到 original server 抓取。

Mosso CloudFiles 使用的 CDN 是 Limelight Networks,這是全世界第二大 CDN,也是 YouTube 在使用 Google 的網路前使用的 CDN。他目前的價錢從 USD$0.22/GB 開始計算,與 Amazon CloudFront 的 Japan Edge 同一個等級,但 Limelight Networks 在 CDN 這塊的功夫比起 Amazon 真的強很多,像是 HiNet 的使用者會導到到美西的伺服器,而非香港的伺服器 (因為 HiNet 到香港的伺服器會走到北美)。

Mosso CloudFiles 的價錢頁面在「Pricing / Scaling」。Amazon CloudFront 的價錢則是在「Pricing」這頁。

比較重要的是 CloudFiles CDN 的 GET request 本身是不算錢的,拿來放 CSS 與 JavaScript 之類的小檔案似乎相當不錯?

除了官方提供了一些 API 外 (以及一些官方提供的 dev library,包括 JavaPHPPythonC#),Perl 的社群也寫了 CPAN module:Net-Mosso-CloudFiles,所以拿來跑 routine job (備份之類的) 應該沒有大問題。

價位與 AWS 都差不多,以儲存空間及頻寬計費,目前 Inbound bandwidth (從外面流入 CloudFiles) 有優惠,可以看一下。

Update:發現兩個大缺點,使得 CloudFiles 沒那麼吸引人了:

  • 透過 Control Panel 砍掉 original server 上的檔案後,CDN edge 不會更新。
  • 不支援 HTTP gzip/deflate。

Update:okay,直接問還是比較有效率的。第一個問題的答案頗糟糕:

@gslin There is a built in TTL - it can be changed vie the API.

是可以設短一點,但實在不太舒服...

在 Greasemonkey 裡破 Megaupload 的 CAPTCHA

CAPTCHA 廣泛的被用在阻擋機器人,一般是給你一張圖片,要求你輸入圖片的字。為了避免用 OCR 破解,CAPTCHA 通常會有各種變化,讓程式難以破解。

Megaupload 的 CAPTCHA 的變化很簡單,像這樣:

於是就有人用 Firefox + Greasemonkey,在純 JavaScript 的環境下以類神經網路破 Megaupload 的 CAPTCHA:「Megaupload auto-fill captcha」。

John Resig 甚至寫了一篇文章分析這隻 Greasemonkey script 的程式碼:「OCR and Neural Nets in JavaScript」,從利用 getImageData 取得圖片內容、轉灰階、切字、去雜訊,到最後計算 Megaupload 的 CAPTCHA...

剛好在 Slashdot 上看到「Building a Better CAPTCHA」也在討論用 CAPTCHA 是否能解決問題。(comment 才是重點)

ppk 的 ppk on JavaScript

星期五晚上去天瓏一趟,把 ppk 寫的《ppk on JavaScript》中文版抱回家看,可以趁著年假沒有網路時翻閱。

英文版是在 2006 年出版的,書評可以參考 othree 寫的「ppk on javascript 書評」,中文版在 2008/8 出版,由 Taobao UED 翻譯。

在講 JavaScript 的歷史時 ppk 提到:

在我寫這本書的時候,Ajax 的熱潮仍然席捲全球。但是我相信他最終會像 DHTML 那樣結束:人們會完全對它失去興趣,而它將會原形畢露,只是少量 JavaScript 和大量的空話,雖然我不知道這會在何時發生。

JavaScript 將回歸瘦時代,那時它的用途將再次被重定義,大型的解決方案將被精巧簡單的腳本所取代。

前面的趨勢似乎不會來臨,Ajax 被大幅證明對於操作介面的幫助,甚至還推動瀏覽器的升級。後面提到的事情,jQuery 這類 JavaScript Library 似乎符合 ppk 的想法。(jQuery UI 是另外一回事了...)

2009 年看 2006 年的人對於未來 (當時的未來) 的猜測還蠻有趣的。

將 Ubuntu 裡的 Java 更換成 Sun 的版本

這篇說的方法在 Debian 可能也一樣,不過暫時沒有打算在有 Debian 的機器上測試。

關於 Ubuntu 的修改,你可以參考「Java - Community Ubuntu Documentation」這篇,我在下面提到的方式會透過 update-alternatives 修改。

裝完 SunJava 後發現還是跑 GNU 的版本,看了 link 結構後猜大概會跟「Ubuntu / Debian 快速修改預設編輯器(nano -> vim)」這篇的方法一樣:

lrwxrwxrwx 1 root root 22 2008-10-27 01:38 java -> /etc/alternatives/java*

所以修改方式是用 root 跑:

# update-alternatives --config java

同理,如果要把 compiler (javac) 也換成 Sun 的版本,用:

# update-alternatives --config javac

就可以了。用 -version 可以驗證:

$ java -version
java version "1.6.0_10"
Java(TM) SE Runtime Environment (build 1.6.0_10-b33)
Java HotSpot(TM) Server VM (build 11.0-b15, mixed mode)
$ javac -version
javac 1.6.0_10

jQuery 1.3.1

John Resig 寫了篇 jQuery 1.3.1 的細節 (順便公告 jQuery 1.3.1 出版了):「jQuery 1.3.1 Released」。

主要包括:

  • 不再提供 packer 版本,最主要的原因是速度,在來世再來是在 Adobe AIRCaja 下會有問題。不過,需要的人還是可以自己壓...
  • 不再支援 Safari 2,主要是市佔率降到很低了,目前 Safari 的主流是 3.x。

1.3.1 修掉的 bug 在「{30} jQuery 1.3.1 Closed Bugs」這裡可以看到。(裡面有一個 enhancement,不太重要?)

Debian 上跑 apache22-mpm-worker

FreeBSD 上跑 Apache 2.2 worker 的方法在「apache22 (worker) + mod_fastcgi + php5-fcgi」這篇寫過了,同樣的架構在 Debian 上跑卻發現比 prefork 還吃記憶體,花了一些時間找,發現是預設的 Stack 太大造成的,所以:

<IfModule mpm_worker_module>
    ThreadStackSize   65536
    ThreadLimit         256
    StartServers          1
    MaxClients          256
    MinSpareThreads       1
    MaxSpareThreads     256
    ThreadsPerChild     256
    MaxRequestsPerChild   0
</IfModule>

加了 ThreadStackSize 這個設定後,每個 thread 的 stack 就會比較小了 (預設超過 1MB,不記得多少了),這個方式跑了一個月後還蠻正常的。

jQuery 1.3

jQuery 1.3 正式版照著預定,在 1/14 放出來了:「jQuery 1.3 and the jQuery Foundation」。1.3 的 release note 可以在「Release:jQuery 1.3」這邊找到。

速度改善很多,主要是 "HTML Injection Rewrite" 的部份改寫後的效果最好。(Selector 的部份還好,本來就很快)

Google AJAX Libraries API 上也有了:http://ajax.googleapis.com/ajax/libs/jquery/1.3/jquery.min.js,要使用的人可以自己設定,不過文件還沒更新。

UpdateJohn ResigTwitter 上提到 1.3 有些 bug,所以下個禮拜可能會出 1.3.1

當機時的道歉?

37signals 上的「The bullshit of outage language」這篇提到當機時 (outage) 這三個詞彙毫無誠意:

  • We apologize
  • Any inconvenience
  • This may have caused

然後第一個 comment 的地方,有人找到之前 37signals 因為 Rackspace 爛掉造成服務中斷時的道歉公告「Downtime notice」:

We deeply apologize for any inconveniences this may have caused and will work hard to make sure we reduce the likelihood of this happening again.

(狂噴淚)