PHP 5.4 的新功能…

PHP 5.4 在 3/1 已經發布了,其中我覺得比較重要的幾個新功能:

  • Traits – 看範例應該就會懂用法了,code reuse用的。
  • 內建Web Server,開發測試的時候不需要設定 apache 或 nginx 了。
  • Closure 裡面支援 $this。
  • $a = [1,2,4,5]; 這樣的 Array Notation。
  • func()[0](new Foo)->bar() 這樣的寫法。
  • json_encode() 的第二個參數可以給 JSON_PRETTY_PRINT(印出人類方便閱讀的 JSON 格式)與 JSON_UNESCAPED_UNICODE(不要 escape unicode 字元)

然後 5.4 剛出的新功能就有 bug 了…XD

Flickr 提供 OAuth Core 1.0a 認證方法

Flickr 今天公佈了一個新功能:OAuth Core 1.0a 認證方法。現有的 API 方法不變,只有認證改用 OAuth Core 1.0a 的方法。原本的認證方法將在明年(2012年)移除。

另外, Flickr 也提供了舊API的轉換認證方式,只要用 Flickr 提供的  flickr.auth.oauth.getAccessToken API 就可以把舊的 Flickr  Access Token 轉為 OAuth 的 Access Token,也就是使用者不需要重新授權一次就可以轉換成 OAuth。

Linode 的 Load Balancer…

長輩那邊看到了Linode 也推出 Load balancer 服務… (剛開始 beta),於是就來測試一下:

這是增加一個 Port 的畫面,可以選 TCP 或 HTTP Protocol(沒有HTTPS),另外可以看Cookie或者查表來把同一個人導到同一台backend上。

Healthy Check 的部份有TCP、HTTP Valid Status 與 HTTP Body Regex,所以可以檢查回傳的頁面是不是正確(例如有沒有</html>)。但是不能指定 Host: 這個 Header。

設定完大概就長這樣:

然後接下來是加入 Member Node:

不能填非 192.168.*.* 或是 IPv6 Link Local Address 以外的值:

討論區的公告上面寫說支援IPv6,不過實際測試發現填不進去:

實際使用上是可以支援 IPv6 的,也有實做 X-Forwarded-For

實際使用上的問題有兩個:

  1. 跟之前的 AWS 的 ELB 一樣,有 Load Balancer IP 的信任問題。沒辦法確認這個 X-Forwarded-For 是不是被假造的。
  2. Node 的 Healthy Check UP/Down Status 更新速度很慢。我今天17:00加了新的Node進去,到現在(21:30)的 Status 還是 Unknown…

Plurk 的 OAuth API…

聲明:我目前是 PIXNET 的員工。PIXNET 提供 OAuth API 服務給 PIXNET 本體與 Murmur.tw

Plurk 最近推出了新的 OAuth Core 1.0a API,終於是不用存帳號密碼了……今天晚上試著寫了一個機器人:台灣漫畫出版情報

現在的主要語言都有提供 OAuth Core 1.0a 的 Library,不過因為某些因素(其實就是懶……),我用的是 ronnywang 寫的 phppixnetapi 來改。其實也只要改掉前面定義的三個 URL,然後各個 function 照著 Plurk 提供的API寫就可以了。

寫完,測試發噗不會動……不過取得 Timeline 倒是成功了。檢查了老半天看不出什麼原因,最後把 POST 改成 GET 就可以了……OTL 真是令人絕望。

另外測試發噗的時候一如往常的遇到 Plurk 的防洪機制XD

Adobe 在 Flash Media Server 裡支援 HTTP Live Streaming

在 NAB 裡面,Adobe宣佈在 Flash Media Server (FMS) 裡支援 HTTP Live Streaming (HLS),也就是 iOS 用的那套 Streaming 方式。

因為 Android 3.0 也支援 HLS,不出意外的話應該會成為新的Streaming標準了。

Update: 不是 Apple ,Adobe 才對。感謝far

Head JS : The only script in your HEAD

head.js是一個很小(只有2.3kb)的javascript程式,主要的功能是可以「非同步」的載入javascript。在head.js自己的網站介紹中,很大膽的說「The only script in your <HEAD>」。更精確的來說,使用head.js以後只需要有一個 script tag載入head.js,其他的 javascript 檔案都可以用head.js來載入。

其實非同步載入javascript的技術已經很成熟了,像是Google Analytics就有提供非同步載入的程式碼。由於Browser在處理<script> tag的時候會block住整個頁面的render(為了要處理 document.write())與頁面上其他 resource 的載入,所以能夠用非同步的方式載入javascript的話,除了不會 blocking render 讓使用者更快看到頁面之外,也可以平行地載入不同的script,加快整個網頁的載入速度。

但是非同步載入有個問題:如何保證執行javascript時的相依性?(例如,一定要先執行完 A script 才能開始執行 B script。)這點要自己處理的話很麻煩,但 head.js 已經幫忙作掉了。

// load files in parallel but execute them in sequence

head.js("file1.js", "file2.js", ... "fileN.js");

這樣的話就會同時載入file[1-N].js,但是按照順序執行file1.js ~ fileN.js。

有人會說,如果全部壓成一個很大的檔案,不就沒有執行順序的問題了嗎?但是壓成大檔的壞處是,即使只更新一個小功能,整個大檔案都必須重新load。另外,iPhone 的 safari 最大只 cache 單檔大小 15~25kb 的檔案1

不過要注意的是,head.js的非同步載入也有一些限制,可以到http://headjs.com/ 去看看 “ Developing with Head JS” 這一段的說明。

除此之外,head.js 還有提供 CSS3 feature detection的功能,在不支援CSS3功能的瀏覽器上,<html>這個元素會被加上相對應的class。例如瀏覽器不支援CSS3 的 borderimage 屬性的話,他的 <html> 元素就會被加上 no-borderimage 這個 class,方便前端工程師寫出替代方案。


另外還有螢幕大小偵測、瀏覽器偵測、HTML5 enabler(讓CSS可以style一些HTML5 tag)等等功能,看起來這些功能的主要目標是放在行動市場。原始碼放在 github

相關閱讀:http://kaix.in/daddy/2010/12/head-js-the-only-script-in-your-head/

  1. http://www.phpied.com/iphone-caching/ []

Google 的 mod_pagespeed

Google 前幾天放出的 Apache Module mod_pagespeed 直接把一些網站最佳化在 Apache 吐出去前作掉:

  • CSS、JS合併
  • Inline CSS 拉出來
  • 設定 Cache-control
  • 縮小圖片大小
  • 拿掉不必要的空白
  • ……

沒有做的最佳化:

  • gzip壓縮(可以用mod_deflate)作掉。

各個Filter可以獨立套用,所以如果你已經有用 YUI Compressor 或者Closure Compiler 的話,可以不需要套用相關的 Filter。

目前還不支援 prefork 以外的 MPM,所以暫時沒辦法測就是……(手邊的機器都跑 worker MPM 了)。

改善 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效能會好……

RSS Cloud 與 Pubsubhubbub

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

PuSH 本身在通知Subscriber的時候,會把更新的資訊內容一起給出來(fat ping)1 。這樣的好處是Subscriber不需要再去Publisher抓,降低Subscriber的實做難度,並且也減輕 Publisher 的負擔。缺點則是 Hub 比較難實做。

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

  1. http://www.techcrunch.com/2009/09/09/rsscloud-vs-pubsubhubbub-why-the-fat-pings-win/ []