發文作者:wekon | 十一月 21, 2008

[20081120 seminar 筆記] simple is hard (Rasmus 校園講座交大場)

e69caae591bde5908d-17
(http://www.registrano.com/events/php-nctu)

學長介紹的演講
PHP 創始人主講
再加上剛好在小龍的 seminar 課舉辦
當然一定要來聽囉

之前看到 JosephJ 的分享 (http://josephj.com/entry.php?id=186)
聽了之後感覺內容大同小異
不過還是將我聽到的東西整理在此

這次演講圍繞在三個重點:
scalability, performance, and security
其中 scalability 及 performance 指的是使用 PHP 如何達到這兩個特性
而 security 指的則是 XSS

scalability

一開始 Rasmus 提到
當 loading 增加,自然就需要多台 server 來處理
PHP is a share-nothing architecture
PHP 本身並不處理 session 或 data 在哪台 server 的控制
這些控制是由其他 tools 來達到的

很多人在設計架構時,因為採用 MVC 架構
所以通常會設計一個 front controller 來分配流量給多台 server
Rasmus 認為這是個錯誤的設計
這不代表不能用 MVC 架構
而是要做到 scalability, 不應該採用 front controller
其實 web browser 本身就已經是個 controller 了
也就是說,browser 上所呈現的內容本來就可以來自不同 server 的處理結果

以 yahoo mail 為例
一個 yahoo mail 的應用,其中會牽涉很多不同的動作
我們可以將不同的動作視為不同的 applications
不同的動作都由不同的 servers 與 protocols 來支援

此時有人提出一個問題:這樣要如何進行安全控管呢
Rasmus 回答,的確,如果是 single entry point 會比較容易控管
他們的作法是使用 library function 來處理
而不是使用 application code 來 filter
(聽不太懂這裡是什麼意思 …)

performance

performace 分為 frontend performance enhancement
以及 backend performance enhancement

frontend performance enhancement 這裡所提到的是 javascript 的用法
一般我們會將 javascript src 的外部檔案連結放在網頁的最前面
然後才開始畫網頁畫面
所以在抓完檔案前不會畫畫面
Rasmus 建議,將 data 分批傳給使用者比較好
也就是一開始先將一部份網頁畫出來
細部的內容再慢慢呈現
這樣才不會讓使用者一直在等待一個空白畫面

至於 backend performance enhancement
主要是要靠一些 profiling 的工具來找出 bottoleneck
然後就可以針對這些地方來改進

其中有一個東西跟 profiling 工具比較無關的
是 APC 的東西
因為 PHP 是直譯式語言
所以需要在 runtime 將 code compile 成 opcode
如果每次都編譯,會浪費時間
所以有了 APC 的設計,將之前 compile 的結果放在 APC stack 中作 cache
Rasmus 建議將 APC 關掉,可以增加處理速度
至於為什麼,我就沒有聽得很清楚了
怎麼想也想不通為什麼關掉反而會比較快
該不會是聽錯大師的意思了 …

在 profiling 工具部分
一開始介紹了一個 Siege,可以用來量測 transaction 來回所花的時間

第二個是 include.so
讓你檢查哪些程式 include 哪些 library
在此,Rasmus 建議不要讓同一個 library 被 include_once 很多次
這樣雖然不會有錯,但是會降低效率
只用 include 就好,但是要保證只被 include 一次
所以他會 maintain 一個 document 來記錄 dependencies of libraries 來避免被重複 include

接下來是 STrace
這是一個 system call level 的 profiling tool
不止開發 PHP 時可以用,在開發 C/C++ ,或各種程式都很好用
他可以讓你看到實際上作了哪些 system call
在這裡舉了一個例子
如果你的 include path 是以 “./" 開頭
則 system call 一開始會找到錯誤的路徑
然後才是正確的
如此一來,就會產生比較多的 system call
如果改用絕對路徑,則可以提升 performance

再來是 Valgrind
這個工具可以產生一個圖形介面的流程圖
讓你知道在跑某隻程式時會經過哪些 function call
並且各花了多少時間
例如發出一個 request
他可以列出 apache 內部經過的 calls, 以及自己寫的 PHP calls

(STrace 跟 Valgrind 的功能怎麼印象中好像可以拿來分析一般程式的運作流程,進而破解的一種工具呢)

最後是 XDebug
針對 PHP 作 profiling
看起來很像 Valgrind
不過他不會跑出 apache calls 這種資訊
只有將 PHP 程式相關的東西畫出來
在這裡他舉了一個例子
如果使用者使用了 XMLWriter
則會發現這個 call 相當花時間
因為他要把 HTML parse 成 DOM tree
所以透過此工具,可以改用別的寫法來提升 performance

最後,還提到了 warninig 的處理
他建議將 warning 全部打開
因為 warning 的產生雖然不會有錯
但是會拖慢系統效率
所以最好是要能將所有 warning 都 debug 掉

security

這部分就跟 PHP 關係不大了
談的是很熱門的 XSS 問題
包括舉了一個 firefox 的 mailto bug 例子
不過我覺得比較有趣的是他們的解決方法

一般 XSS 會發生經常是在 input 的地方沒處理好
所以會需要一個 filter 來先篩選
一般人是針對幾種危險的情形來一一檔掉
然而,到底哪些是危險的呢,這很難防範
往往會有意想不到的特殊 input 沒考慮到
比如編碼過的 input
但 Rasmus 認為要反過來,先將全部 input deny,然後再開放允許的 input
這個觀念就像是防火牆
不會有人只設定哪些 port 要擋的
都是設定全擋,然後哪些例外要開的
只允許少部分的 input 可以進來
這樣一來就可以比較能確保 input 是安全的了

整場聽完
真是覺得獲益良多呀
雖然還沒有到達那種開發大型網站的程度
不過能夠一窺 PHP 用在大型網站的開發原則
感覺學到了很多

References

slides: http://talks.php.net/show/nctu
osephJ: http://josephj.com/entry.php?id=186
php user group: http://twpug.net/modules/newbb/viewtopic.php?topic_id=3676&forum=9&post_id=13851


Responses

  1. 好認真詳盡的筆記, 像是讓我再聽了一次演講一樣🙂

  2. 總覺得要把聽到的東西趕快記起來,以免一下就忘了🙂


發表迴響

在下方填入你的資料或按右方圖示以社群網站登入:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / 變更 )

Twitter picture

You are commenting using your Twitter account. Log Out / 變更 )

Facebook照片

You are commenting using your Facebook account. Log Out / 變更 )

Google+ photo

You are commenting using your Google+ account. Log Out / 變更 )

連結到 %s

分類

%d 位部落客按了讚: