Category: Network

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

Amazon Web Service 新增日本東京機房

Amazon Web Service (AWS) 繼去年在新加坡提供服務之後，今日又宣佈了於日本東京新增機房提供服務。常用的服務像EC2、S3等都有提供，可以改善從台灣使用 AWS 的 response time。

價格的話約比新加坡的點貴了 6~7% （頻寬、儲存空間或是CPU都是）。
RTT 約為 40ms 左右，從台灣固網過去的品質比較好，中華電信的話還有去回不同路的問題（看起來繞到大阪去了……），按照新加坡的經驗，大概再兩三個月就會 tune 的差不多了。

現在的價錢還是偏高一些，不過 AWS 有定期降價的好習慣，所以應該可以期待年底能提供更優惠的價格。

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 的檔案 ((http://www.phpied.com/iphone-caching/)) 。

不過要注意的是，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/

	


	
	






	
	

		
AWS 推出 Anycast DNS 服務：Amazon Route 53
	


	

		
AWS今天推出Amazon Route 53，本質上是一個DNS Hosting服務，價格是每一百萬個 DNS Query收費USD$0.5，超過十億個Query後每百萬個USD$0.25，然後每個Domain每個月要多收USD$1。


根據Amazon CTO Werner Vogels的說法，採用的是Anycast的技術。在全球有16個點，包含亞洲的香港、東京與新加坡。實測起來，從台灣到亞洲的Routing還不錯，但美國的Routing有點不夠好，有的地方RTT大概還要接近100ms。


另外，尚未支援wildcard以及在一個zone file裡面有subdomain的entry，你必需要另外切開成另一個zone file。目前也不能當作其他DNS Server的Slave。


如果未來能夠支援從別的DNS master server 用 zone transfer 的方式進入Route 53的話，使用的彈性會大非常多。


2010/12/17 Updated:  今天的 AWS Webinar 說明了現在已經支援 wildcard! 剛剛實測的結果，在一個 zone file 放 subdomain 的 entry 的功能也支援了，現在已經不需要另外切開成另一個 zone file。

	


	
	






	
	

		
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. 

  2. 上 OP Code Cache     
    例如 APC 之類的OP Code Cache可以避免每次執行的時候，PHP都去 compile 一次原始程式碼。
    3. 

  3. 避免大量的 require、include，或是把需要 require 與 include 的檔案都放在同一個目錄下     
    因為 realpath() 很吃資源…也可以考慮加大 realpath cache。
    4. 

  4. Cache     
    考慮把資料庫輸出 cache，或甚至 cache 整個 HTML。
    5. 

  5. 把 static file 與動態 file 分開     
    講到爛的東西了。
    6. 



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