改善 Apache + PHP 效能的一些想法…

雖然現在已經是 Rails 或是 Python 的時代了(以上兩個語言隨便都可以跑出 1000 req/s 的成績,反觀 PHP 在 production 最多也才 200 req/s)。不過 PHP 畢竟還是一個大量應用在 Web 環境的語言,尤其是 WordPress 也還是用 PHP……

  1. 使用 fastcgi mode + Apache Worker 或是 Thread MPM
    PHP 本身雖然是 Thread safe 的,但是PHP的 Module 很多不是(如 mysql module),所以如果要用 Apache PHP Module的話,只能用 prefork MPM。而 prefork 一隻 httpd 動輒 200MB,有時候還高達 2GB,造成效能不彰。另外一個重點是 fastcgi 會自己重跑,可以避免 memory leak 問題。
  2. 上 OP Code Cache
    例如 APC 之類的OP Code Cache可以避免每次執行的時候,PHP都去 compile 一次原始程式碼。
  3. 避免大量的 require、include,或是把需要 require 與 include 的檔案都放在同一個目錄下
    因為 realpath() 很吃資源…也可以考慮加大 realpath cache
  4. Cache
    考慮把資料庫輸出 cache,或甚至 cache 整個 HTML。
  5. 把 static file 與動態 file 分開
    講到爛的東西了。

另外PHP是個不適合OO的語言,不要期待使用OO的PHP效能會好……

VP8 Open Source,名為WebM

這幾天Google IO 2010的消息之一:VP8 Open Source,命名為WebM,程式碼本體以 3-clause BSD style 授權發布,而Bitstream檔案格式以CC-by 3.0發布。

目前 FirefoxOpera 的使用者可以下載 WebM 的測試 build。Chromium (Chrome的開放原始碼版本) 也已經可以取得原始碼自己編譯,而預先編譯好的版本 (dev channel build) 還要等個幾天。

目前 YouTube 已經支援以 VP8 播放影片,只要開啟 HTML 5 模式,然後在影片URL後面加上 &webm=1 即可。

Flash 已經宣佈會在接下來的版本內建支援WebM,而微軟也宣佈將在IE9中支援 ((使用者必須在系統內安裝相關的 codec))。接下來就看 Apple 的反應了。

FreeBSD 的 pf route-to 與 TSO (TCP Segmentation Offload)

之前一直有遇到在 pf 裡面用 route-to 之後網路連線緩慢的問題(大概只有 10kb/s),不過一直沒時間去追。最近花了點時間去追這個問題,發現在使用 route-to 並且開啟 TSO 之後,重送以及 out-of-order 的 packet 變得異常多:

wireshark.png

拿掉 TSO 或是 route-to 其中一個設定,狀況就會變好。在 core team 修正這個 bug 之前,只好先暫時 disable TSO 了。

RSS Cloud 與 Pubsubhubbub

RSS CloudPubsubhubbub (PuSH) 兩者都是 RSS 的 extension,提供一個機制讓Subcriber可以即時接受Publisher的更新。對於Publisher 來說,兩者的實做方式差不多,不需要作什麼大改變:只要在有內容更新的時候送一個 ping 給 hub,並且在 RSS Feed 裡面指定 hub 的位置即可;不過對於Subscriber來說,做的事情就不太一樣。

PuSH 本身在通知Subscriber的時候,會把更新的資訊內容一起給出來(fat ping) ((http://www.techcrunch.com/2009/09/09/rsscloud-vs-pubsubhubbub-why-the-fat-pings-win/)) 。這樣的好處是Subscriber不需要再去Publisher抓,降低Subscriber的實做難度,並且也減輕 Publisher 的負擔。缺點則是 Hub 比較難實做。

我覺得兩者都可以視為 Blog Ping 的延伸。以後 Publisher 不需要自己去一家一家 Ping,只要 Ping hub,其他就交給 hub 就好了。

IE 外嵌 JavaScript 的問題

當 IE 用 <script>外嵌一個 javascript 的時候,只刪除 IE 的 Cache 是無法刪除被 IE Cache 住的 Javascript 的。有幾種方法可以解決:

  1. 請使用者把「所有的」Cache 以及紀錄都刪除。可以用
    RunDll32.exe InetCpl.cpl,ClearMyTracksByProcess 4351
    這個指令作到。
  2. 請使用者按 Ctrl+Shift+重新整理。
  3. 在 script URL 後面加上不同的 QueryString。

如果可以控制 script URL,第三個方法是最簡單而且最有效的方法。

支援超多技術的 Multiple File Uploader

這年頭上傳檔案要是沒辦法一次選很多個檔案上傳,可能會有很多人幹樵;從最老牌的swfuploadHTML 5 File API都支援,不過Flash吃資源,而且swfupload的更新速度老實說不快;HTML 5則不是每家瀏覽器都支援。於是,TinyMCE的作者們就寫了plupload,只要瀏覽器支援Google Gears、Flash、Sliverlight、Yahoo Browser Plus,或是HTML 5 File API的其中任何一項,就可以一次選擇很多檔案上傳!

看看支援的功能,除了Multi Threading和Pipeline以外,包括事先縮圖和Drag&Drop都實做出來了,看起來非常exciting啊……

不過我有預感bug應該也會很多就是。

看起來IPv6好像有那麼一點可能性了

最近有一堆IPv4位址即將用完的新聞,連1.0.0.0/8都被拿出來用了;再加上有國外的ISP開始測試提供用戶IPv6服務,看起來是有那麼一點在這幾年開始轉移到IPv6的可能性。

Hinet也開始在光世代線路測試IPv6了,而且是用Dual Stack供裝。據說目前只有一些機房有提供測試,如果剛好連線到的機房沒提供,還要跳線才行。

反正就慢慢來吧……1998年制定的IPv6,也才經過11個年頭而已。

第一個 CPAN Module

CPAN 是 Perl 很重要的資源之一,其中 Perl Modules 更是重點中的重點。之前想要把自己寫的一些 Module 傳上去,不過看到說明中的 “Please allow three weeks for proceeding” 就完全提不起勁了……

後來想說乾脆註冊起來放。沒想到才送出註冊請求兩小時,帳號就開好了……而且還是台灣時間晚上六點這種美國還是清晨六點的時間耶!

所以說,就把一些 SMS::TW::Drivers 放上去了。另外當然也順手做了 FreeBSD Ports,也方便自己使用。

梵谷‧燃燒的靈魂

479px-Vincent_Willem_van_Gogh_128[1] 
梵谷最有名的向日葵畫作之一,這次台灣沒有展出。

今天去參觀了梵谷.燃燒的靈魂特展。像是柏樹要從畫裡面長出來的油畫,還有略帶憂鬱的自畫像,這次都有來台灣喔!

477px-VanGogh_1887_Selbstbildnis[1]#160;
梵谷1887年的自畫像,這次有來台灣展出。

467px-Van_Gogh_-_Country_road_in_Provence_by_night[1]
有柏樹的夜晚道路。

梵谷油畫厚重的上色方式,即使在超過百年後的今天,仍然可以深深地感受到他的熱情。如果要用一個字說明他的油畫,我最想用的字是 Excited。

我相信無論再過五十、一百年,透過畫布呈現的梵谷內心,一定還是熱情澎湃的。