| 導購 | 订阅 | 在线投稿
分享
 
 
 

Web應用優化技巧

2008-12-28 07:39:36  編輯來源:互聯網  简体版  手機版  移動版  評論  字體: ||
 

作者:Fenng|可以轉載, 轉載時務必以超鏈接形式標明文章原始出處和作者信息及版權聲明

網址:http://www.dbanotes.net/web/flickr_web_tech.html

Cal Henderson是大名鼎鼎的Flickr網站的開發者之一.在一篇名爲Serving JavaScript Fast的文章中,他介紹了用于 Flickr 站點應用優化的技巧,讀罷感覺獲益良多."嚼一下別人的馍",概括一下該文的主要內容.

Flickr是 Web 2.0 的代表站點。面對的網絡問題除了一般 Web 站點都會有的內容優化之外, 還有必須要靈活處理 JavaScript 與CSS的頻繁變化後部署分發帶來的複雜性。

設定文件大小的策略首先面臨的一個問題是把所有的 JavaScript 與CSS放到一個文件中好呢,還是分割成多個文件 ? 從減少網絡請求的角度上考慮, 前者更好,後者差。但是從並行的角度考慮,IE與 Firefox 默認情況下都只能同時從一個域請求兩個資源. 這會在很多情況下給用戶帶來不良的使用體驗--必須所有的文件都下載完畢才可以看到像樣的頁面. Flickr 采用了折衷的辦法--在保持文件數量盡可能少的情況下,把 JavaScript 與CSS分成多個子文件. 這在開發上帶來了複雜性,但是對性能的收益是巨大的。

壓縮的優化問題毫無疑問,對站點內容進行壓縮是一個比較常用的 Web 優化手段.但是並不一定都能達到理想的效果.原因在于mod-gzip模塊不但消耗服務器端CPU資源,也消耗客戶端CPU資源. 而且, mod_gzip 壓縮文件後創建的臨時文件是放到磁盤上的,這也會給磁盤IO帶來嚴重的問題. Flickr 采用的是 Httpd 2.x 以後支持的mod_deflate模塊.壓縮操作都在內存中進行.mod_deflate 在 Httpd 1.x 是不可用的, 不過可以通過創建RAM盤的方式來間接提高性能.

當然, mod_gzip 到也不是一無是處, 對于預壓縮的文件, 還是有好處的. 而且, 采用壓縮的時候,也要注意策略. 圖片文件壓縮就沒什麽必要了(Flickr 上圖像多, 而且壓縮得不到什麽好處). Flickr 只對 JavaScript 和CSS進行壓縮. mod_gzip 新一點的版本能夠自動通過配置 mod_gzip_update_static 選項自動處理 預壓縮的文件. Cal 也指出這個特性在一些舊版本的浏覽器上會出問題.

壓縮的另一個主要手段是內容的壓縮. 針對 JavaScript 可以進行通過減少注釋、合並空格、使用緊湊的語法等小技巧(Google 的所有腳本都非常難讀,而且非常緊湊,思想類似).當然,經過這樣處理的 JavaScript 可能帶了很多括號不容易解析,Flickr使用了Dojo Compressor來構建解析樹。Dojo Compressor 開銷很低,而且對于最終用戶是透明的. JavaScript 的處理方法介紹過,CSS 處理則相對簡單.通過簡單的正則表達式替換(比如把多個空格替換爲一個空格符), 最高可以獲得 50% 的壓縮比。

Caching 的優化Flickr的開發者充分利用了 Http 1.1 規範定義的Etag 與 Last-Modified 機制來提高 Caching 的效率. 值得注意的是,Cal 介紹了一個在負載均衡條件下的 e-Tag 小技巧. 即可以設定 Apache 通過文件調整時間與文件大小獲得 E-Tag ,而默認情況下, Apache 是通過文件節點獲取 e-Tag 的。當然,這也不是很完美,因爲會影響 if-modified-since 。

靈活運用 mod_rewrite據說Flickr網站應用是進行每日構建的(Daily Build)。 如果沒有一個靈活的機制恐怕這是不可想象的。而且,在 Flickr 這樣的站點, 內容的修改同步的處理都是很讓人頭疼的難題. 他們的利器是mod_rewrite的靈活運用。通過配置URL重寫規則,很容易切換到不同的環境下。聽起來很簡單, 但是沒有一定的 Web 技術功力談何容易做到 ?!

通過這幾個主要方法的運用,我們看到了如夢幻一般高性能的Flickr.

BTW: 因爲在 Flickr 在國內沒有服務器, 大陸用戶訪問的速度就別提了 :(

--End.

這篇 【Flickr 的開發者的 Web 應用優化技巧】來自dbanotes.net

 
作者:Fenng|可以轉載, 轉載時務必以超鏈接形式標明文章原始出處和作者信息及版權聲明 網址:http://www.dbanotes.net/web/flickr_web_tech.html Cal Henderson 是大名鼎鼎的Flickr網站的開發者之一.在一篇名爲Serving JavaScript Fast的文章中,他介紹了用于 Flickr 站點應用優化的技巧,讀罷感覺獲益良多."嚼一下別人的馍",概括一下該文的主要內容. Flickr是 Web 2.0 的代表站點。面對的網絡問題除了一般 Web 站點都會有的內容優化之外, 還有必須要靈活處理 JavaScript 與CSS的頻繁變化後部署分發帶來的複雜性。 設定文件大小的策略首先面臨的一個問題是把所有的 JavaScript 與CSS放到一個文件中好呢,還是分割成多個文件 ? 從減少網絡請求的角度上考慮, 前者更好,後者差。但是從並行的角度考慮,IE與 Firefox 默認情況下都只能同時從一個域請求兩個資源. 這會在很多情況下給用戶帶來不良的使用體驗--必須所有的文件都下載完畢才可以看到像樣的頁面. Flickr 采用了折衷的辦法--在保持文件數量盡可能少的情況下,把 JavaScript 與CSS分成多個子文件. 這在開發上帶來了複雜性,但是對性能的收益是巨大的。 壓縮的優化問題毫無疑問,對站點內容進行壓縮是一個比較常用的 Web 優化手段.但是並不一定都能達到理想的效果.原因在于mod-gzip模塊不但消耗服務器端CPU資源,也消耗客戶端CPU資源. 而且, mod_gzip 壓縮文件後創建的臨時文件是放到磁盤上的,這也會給磁盤IO帶來嚴重的問題. Flickr 采用的是 Httpd 2.x 以後支持的 mod_deflate模塊.壓縮操作都在內存中進行.mod_deflate 在 Httpd 1.x 是不可用的, 不過可以通過創建RAM盤的方式來間接提高性能. 當然, mod_gzip 到也不是一無是處, 對于預壓縮的文件, 還是有好處的. 而且, 采用壓縮的時候,也要注意策略. 圖片文件壓縮就沒什麽必要了(Flickr 上圖像多, 而且壓縮得不到什麽好處). Flickr 只對 JavaScript 和CSS進行壓縮. mod_gzip 新一點的版本能夠自動通過配置 mod_gzip_update_static 選項自動處理 預壓縮的文件. Cal 也指出這個特性在一些舊版本的浏覽器上會出問題. 壓縮的另一個主要手段是內容的壓縮. 針對 JavaScript 可以進行通過減少注釋、合並空格、使用緊湊的語法等小技巧(Google 的所有腳本都非常難讀,而且非常緊湊,思想類似).當然,經過這樣處理的 JavaScript 可能帶了很多括號不容易解析,Flickr使用了Dojo Compressor來構建解析樹。Dojo Compressor 開銷很低,而且對于最終用戶是透明的. JavaScript 的處理方法介紹過,CSS 處理則相對簡單.通過簡單的正則表達式替換(比如把多個空格替換爲一個空格符), 最高可以獲得 50% 的壓縮比。 Caching 的優化Flickr的開發者充分利用了 Http 1.1 規範定義的Etag 與 Last-Modified 機制來提高 Caching 的效率. 值得注意的是,Cal 介紹了一個在負載均衡條件下的 e-Tag 小技巧. 即可以設定 Apache 通過文件調整時間與文件大小獲得 E-Tag ,而默認情況下, Apache 是通過文件節點獲取 e-Tag 的。當然,這也不是很完美,因爲會影響 if-modified-since 。 靈活運用 mod_rewrite據說Flickr網站應用是進行每日構建的(Daily Build)。 如果沒有一個靈活的機制恐怕這是不可想象的。而且,在 Flickr 這樣的站點, 內容的修改同步的處理都是很讓人頭疼的難題. 他們的利器是mod_rewrite的靈活運用。通過配置URL重寫規則,很容易切換到不同的環境下。聽起來很簡單, 但是沒有一定的 Web 技術功力談何容易做到 ?! 通過這幾個主要方法的運用,我們看到了如夢幻一般高性能的Flickr. BTW: 因爲在 Flickr 在國內沒有服務器, 大陸用戶訪問的速度就別提了 :( --End. 這篇 【Flickr 的開發者的 Web 應用優化技巧】來自dbanotes.net
󰈣󰈤
王朝萬家燈火計劃
期待原創作者加盟
 
 
 
>>返回首頁<<
 
 
 
 
 熱帖排行
 
王朝網路微信公眾號
微信掃碼關註本站公眾號 wangchaonetcn
 
 
靜靜地坐在廢墟上,四周的荒凉一望無際,忽然覺得,淒涼也很美
© 2005- 王朝網路 版權所有