大型Web2.0站點建構技術初探(一)

大型Web2.0站點建構技術初探(一)

大型Web2.0站點建構技術初探 一、 web2.0網站常用可用性功能子產品分析 二、 Flickr的幕後故事 三、 YouTube 的架構擴充 四、 mixi.jp：使用開源軟體搭建的可擴充SNS網站 五、 Technorati的背景資料庫架構 六、 通過了解MySpace的六次重構經曆,來認識分布式系統到底該如何建立 七、 從LiveJournal背景發展看大規模網站性能優化方法 八、 說說大型高并發高負載網站的系統架構 一、 web2.0網站常用可用性功能子產品分析 Web 2.0網站是指将傳統的網站構架（平台、内容源、使用者、傳播方式等）轉化到以使用者為核心的網站構架上來，包括一系列展現web2.0概念的元素、定位和創意。web2.0網站在構架上須展現兩大宗旨，即強大的背景系統和簡單的前台頁面，也即提供良好的使用者體驗，展現以人為本，技術服務人類的宗旨。 web2.0網站常用功能塊通常包括以下幾大項： 1. Tag标簽功能塊 Tag(中文叫做"标簽") 是一種新的組織和管理線上資訊的方式。它不同于傳統的、針對檔案本身的關鍵字檢索，而是一種模糊化、智能化的分類。 　　網頁使用Tag标簽的好處： 為頁面設定一個或者多個Tag标簽可以引導讀者閱讀更多相關文章，為别人帶去流量同理也為自己帶來流量。 可以幫助讀者及時了解一些未知的概念和知識點，提高使用者體驗。 Tag是人的意志和趨向的展現，Tag可以幫助你找到興趣相投的人。 　　基于以上優勢，Tag标簽代替了傳統的分類法，成為web2.0網站使用率最高的功能塊（與其說是功能塊倒不如說是一種内容導航和内容組織形式）。 　　一句話：Tag标簽是一種更靈活的分類方法，功能在于引導，特點是無處不在，展現智能性、模糊性和趨向性。 2. RSS訂閱功能塊 RSS是線上共享内容的一種簡易方式（也叫聚合内容，Really Simple Syndication）。通常在時效性比較強的内容上使用RSS訂閱能更快速擷取資訊，網站提供RSS輸出，有利于讓使用者擷取網站内容的最新更新。網絡使用者可以在用戶端借助于支援RSS的聚合工具軟體（例如SharpReader,NewzCrawler、FeedDemon），在不打開網站内容頁面的情況下閱讀支援RSS輸出的網站内容。 RSS訂閱的方式： 訂閱到用戶端軟體如周伯通、遨遊浏覽器RSS閱讀、Foxmail RSS閱讀等，此方式使用者較多 訂閱到線上閱讀（聚合類）門戶網站如Google Reader，Yahoo Reader，抓蝦、Gougou等，省去了安裝RSS閱讀器的麻煩 訂閱到線上單使用者聚合器如Lilina等，比較靈活 RSS訂閱功能的最大好處是定向投遞，也就是說RSS機制更能展現使用者的意願和個性，擷取資訊的方式也最直接和簡單，這是RSS訂閱功能備受青睐的一大主要原因。 3. 推薦和收藏功能塊 　　說到推薦功能，不僅web2.0網站在大量使用，傳統的以cms平台為代表的内容模式的網站也在大量使用，推薦功能主要是指向一些網摘或者聚合類門戶網站推薦自己所浏覽到的網頁。當然，一種變相的推薦就是閱讀者的自我收藏行為，在共享的模式下也能起到推薦的作用。 　　比較有名的推薦目标有以del.icio.us為代表的網摘類網站包括國内比較有名氣的365key、和訊網摘、新浪vivi、天極網摘等。這裡值得一提的是前段時間曾湧現了大批網摘類網站，但他們堅持活下來的好像沒有幾個了，推薦使用前面提到的這幾個網摘門戶，人氣基本上是使最旺的。 4. 評論和留言功能塊 web2.0強調參與性，強調發揮使用者的主導作用，這裡的參與性除了所謂的訂閱、推薦功能外更多地展現在使用者對内容的評價和态度，這就要靠評論功能塊來完成。一個典型的web2.0網站或者說一個能展現人氣的web2.0網站都會花大量篇幅來展現使用者的觀點和視覺。這裡尤其要提到web2.0中的帶頭老大web blog，評論功能已經成為部落客人與浏覽者交流的主要陣地，是展現網站人氣的最直覺因素。 　　評論功能塊應用在部落格系統中實際上已經和部落格内容相分離，而更好的應用恰恰是一些以點評為主的web2.0網站比如豆瓣、點評網等，這裡的評論功能塊直接制造了内容也極大地展現了網站的人氣，是以說評論功能塊是web2.0網站最有力的武器。 5. 站内搜尋功能塊 　　搜尋是資訊來源最直接的方式之一，無論你的網站是否打上web2.0的烙印，搜尋對于一個體系龐大、内容豐富的大型網站都是非常必要的。Tag标簽在某種程度上起到搜尋的作用，它能夠有效聚合以此Tag為關鍵詞的内容，但這種情況的前提是此Tag标簽對浏覽者是可見的，也就是說當Tag标簽擺在浏覽者的眼前時才成立，而對于那些浏覽者想要的資訊卻沒有Tag标簽來引導時搜尋就是達到此目的的最好方法。 　　對于web2.0網站，站内搜尋以标題或者Tag為搜尋域都能起到好的效果，但本人不建議使用内容搜尋域，因為這不符合搜尋的高效性原則。同時，具有突出關鍵詞的内容往往都可以用Tag标簽來引導，是以使用内容域來搜尋實際上是一種浪費伺服器資源的行為，而且搜尋結果的準确性将大打折扣。 6. 群組功能塊 　　我為什麼要把群組作為web2.0網站的功能塊來分析呢，因為群組是web2.0網站的一大特點，也是web2.0所要展現的服務宗旨所在。一個web2.0網站，部落格也好、播客也好、點評也好，抑或是網摘、聚合門戶，他們都強調人的參與性。物以類聚、人以群分，每個參與者都有自己的興趣趨向，web2.0網站的另一主要功能就是幫助這些人找到同樣興趣的人并形成一個活躍的群體，這是web2.0網站的根本。 總結：web2.0網站倡導的是集體創作、共享資源，靠的是人氣，展現的是參與性，一個沒有參與性的web2.0網站都不足以成為web2.0。以上提到的這幾個功能塊就是以吸引使用者參與和引導使用者參與為目的的，真正的web2.0不是什麼深奧的東西，隻有一點，那就是如何讓浏覽者沸騰起來。 二、 Flickr的幕後故事 我們都看到 Flickr 的成功，而又有多少"精英"們了解過 Flickr 背後的過程是多麼充滿艱險。 Flickr 是全 CGI 的動态構架，并以一種 .gne 的腳本作為 CGI 程式語言。不管網站制作菜鳥還是高手都會疑惑：gne 是哪種程式語言？答案：gne 不是一種語言，Flickr 是以極為經典的 PHP + MySQL 方式實作的，在被 Yahoo 收購伺服器搬入美國之前，使用了 21 台（69.90.111.101-121） Apache/PHP 做 Web、23 台圖檔伺服器、另有 MySQL 伺服器組成的資料庫叢集的伺服器數量未知。現在估計使用的是 Yahoo 的負載均衡系統，對外隻有一個 Web 的 IP 和圖檔伺服器的 IP 了。 　　那為何 .php 的檔案要改成 .gne 呢？以往有大型網站為向後相容性考慮，隐藏以程式語言命名的腳本檔案擴充名，比如 Baidu 隐藏了 .php（Google 的 http 伺服器是自己寫的，整合了腳本程式，個别頁面是 .py--Python）；還有一些網站是改成自己網站名相關的擴充名，如 MSN 的群組則是 .msnw，榕樹下是 .rs。 　　那 Flickr 的 gne 是什麼意思？我在維基百科的 Flickr 條目上找到了答案(中文 Flickr 條目上沒有寫明) 。原來 GNE 是 Game NeverEnding 的縮寫，Flickr 的開發者 Ludicorp 在 2002-2004 年一直在開發這套以 Game NerverEnding 為名稱的大型多人線上角色扮演遊戲--一套基于浏覽器的 Web 遊戲系統，個人以為應該就是當年九城的虛拟城市。但是開發近 3 年後該計劃不得不破産，最終隻釋出了一個 Beta 版，而 Ludicorp 将這套系統稍加移植，就有了 Flickr。呵呵，原來 gne 是一個項目的名稱。關于 GNE 的一些連接配接：http://del.icio.us/schee/gne。 　　早期的 Flickr 想做成在類似聊天室的地方讓網友分享、交流自己的照片，注重社群形式和保護照片不被外部引用（見徐子涵2004年的文章），可能是看到了 Hello 的模式吧。但是聰明的 Flickr 團隊不久就改變了政策，淡化了傳統的社群形式--如聊天室、而加強了現在使其功成名就的 Tag 組織形式，一種更自由更随興更輕松好玩的大社群形式，或者叫它廣義社群吧，我随便叫的，可能太學究，看着别太在意就是了。另外，将原來照片隻能在 Flash 内浏覽的限制區除了，并大力推薦使用者将照片引用到自己的 Blog，這無疑對于挑戰傳統相冊系統有決定性意義。減少 Flash 後的網頁更多地引進了新興的 Ajax 技術，使界面操作變得非常 Cool。 　　這就是 Flickr 的曆史，清晰地看到了他們對于優秀産品的執著。有了技術和經驗積累，加上不斷堅持，總有一天時來運轉，你的産品會成為新潮流的裡程碑。 　　還有一句話要告訴 Yupoo 等：把 Flickr 想成一個有 Tag 功能的線上相冊就已經錯遠了；複制粘貼者們想當然将 Flickr 去其糟粕取其精華，結果無關緊要的拿來了，将令人激動的優點都去掉了，結果剩下什麼？ 三、 YouTube 的架構擴充 在西雅圖擴充性的技術研讨會上，YouTube 的 Cuong Do 做了關于 YouTube Scalability 的報告。視訊内容在 Google Video 上有(位址)，可惜國内使用者看不到。 Kyle Cordes 對這個視訊中的内容做了介紹。裡面有不少技術性的内容。值得分享一下。(Kyle Cordes 的介紹是本文的主要來源) 簡單的說 YouTube 的資料流量, "一天的YouTube流量相當于發送750億封電子郵件.", 2006 年中就有消息說每日 PV 超過 1 億,現在? 更誇張了,"每天有10億次下載下傳以及6,5000次上傳", 真假姑且不論, 的确是超乎尋常的海量. 國内的網際網路應用,但從資料量來看,怕是隻有 51.com 有這個規模. 但技術上和 YouTube 就沒法子比了. 1. Web 伺服器 YouTube 出于開發速度的考慮，大部分代碼都是 Python 開發的。Web 伺服器有部分是 Apache， 用 FastCGI 模式。對于視訊内容則用 Lighttpd 。據我所知，MySpace 也有部分伺服器用 Lighttpd ，但量不大。YouTube 是 Lighttpd 最成功的案例。(國内用 Lighttpd 站點不多，豆瓣用的比較舒服。by Fenng) 2. 視訊 視訊的縮略圖(Thumbnails)給伺服器帶來了很大的挑戰。每個視訊平均有4個縮略圖，而每個 Web 頁面上更是有多個，每秒鐘因為這個帶來的磁盤 IO 請求太大。YouTube 技術人員啟用了單獨的伺服器群組來承擔這個壓力，并且針對 Cache 和 OS 做了部分優化。另一方面，縮略圖請求的壓力導緻 Lighttpd 性能下降。通過 Hack Lighttpd 增加更多的 worker 線程很大程度解決了問題。而最新的解決方案是起用了 Google 的 BigTable， 這下子從性能、容錯、緩存上都有更好表現。看人家這收購的，好鋼用在了刀刃上。 出于備援的考慮，每個視訊檔案放在一組迷你 Cluster 上，所謂 "迷你 Cluster" 就是一組具有相同内容的伺服器。最火的視訊放在 CDN 上，這樣自己的伺服器隻需要承擔一些"漏網"的随即通路即可。YouTube 使用簡單、廉價、通用的硬體，這一點和 Google 風格倒是一緻。至于維護手段，也都是常見的工具，如 rsync, SSH 等，隻不過人家更手熟罷了。 3. 資料庫 YouTube 用 MySQL 存儲中繼資料--使用者資訊、視訊資訊什麼的。資料庫伺服器曾經一度遇到 SWAP 颠簸的問題，解決辦法是删掉了 SWAP 分區! 管用。 最初的 DB 隻有 10 塊硬碟，RAID 10 ，後來追加了一組 RAID 1。夠省的。這一波 Web 2.0 公司很少有用 Oracle 的(我知道的隻有 Bebo,參見這裡). 在擴充性方面，路線也是和其他站點類似，複制，分散 IO。最終的解決之道是"分區",這個不是資料庫層面的表分區，而是業務層面的分區(在使用者名字或者 ID 上做文章,應用程式控制查找機制) YouTube 也用 Memcached. 很想了解一下國内 Web 2.0 網站的資料資訊,有誰可以提供一點 ? 四、 mixi.jp：使用開源軟體搭建的可擴充SNS網站 Mixi目前是日本排名第三的網站，全球排名42，主要提供SNS服務：日記，群組，站内消息，評論，相冊等等，是日本最大的SNS網站。Mixi從2003年12月份開始開發，由現在它的CTO - Batara Kesuma一個人焊，焊了四個月，在2004年2月份開始上線運作。兩個月後就注冊了1w使用者，日通路量60wPV。在随後的一年裡，使用者增長到了21w，第二年，增長到了200w。到今年四月份已經增長到370w注冊使用者，并且還在以每天1.5w人的注冊量增長。這些使用者中70%是活躍使用者（活躍使用者：三天内至少登入一次的使用者），平均每個使用者每周線上時間為将近3個半小時。 下面我們來看它的技術架構。Mixi采用開源軟體作為架構的基礎：Linux 2.6，Apache 2.0，MySQL，Perl 5.8，memcached，Squid等等。到目前為止已經有100多台MySQL資料庫伺服器，并且在以每月10多台的速度增長。Mixi的資料庫連接配接方式采用的是每次查詢都進行連接配接，而不是持久連接配接。資料庫大多數是以InnoDB方式運作。Mixi解決擴充問題主要依賴于對資料庫的切分。 首先進行垂直切分，按照表的内容将不同的表劃分到不同的資料庫中。然後是水準切分，根據使用者的ID将不同使用者的内容再劃分的不同的資料庫中，這是比較通常的做法，也很管用。劃分的關鍵還是在于應用中的實作，需要将操作封裝在在資料層，而盡量不影響業務層。當然完全不改變邏輯層也不可能，這時候最能檢驗以前的設計是否到位，如果以前設計的不錯，那建立連接配接的時候傳個表名，使用者ID進去差不多就解決問題了，而以前如果sql代碼到處飛，或者資料層封裝的不太好的話那就累了。 這樣做了以後并不能從根本上解決問題，尤其是對于像mixi這種SNS網站，頁面上往往需要引用大量的使用者資訊，好友資訊，圖檔，文章資訊，跨表，跨庫操作相當多。這個時候就需要發揮memcached的作用了，用大記憶體把這些不變的資料全都緩存起來，而當修改時就通知cache過期，這樣應用層基本上就可以解決大部分問題了，隻會有很小一部分請求穿透應用層，用到資料庫。Mixi的經驗是平均每個頁面的加載時間在0.02秒左右（當然根據頁面大小情況不盡相似），可以說明這種做法是行之有效的。Mixi一共在32台機器上有緩存伺服器，每個Cache Server 2G記憶體，這些Cache Server與App Server裝在一起。因為Cache Server對CPU消耗不大，而有了Cache Server的支援，App Server對記憶體要求也不是太高，是以可以和平共處，更有效的利用資源。 圖檔的處理就顯得相對簡單的多了。對于mixi而言，圖像主要有兩部分：一部分是經常要使用到的，像使用者頭像，群組的頭像等等，大概有100多GB，它們被Squid和CDN所緩存，命中率相對比較高；另一部分是使用者上傳的大量照片，它們的個體通路量相對而言比較小，命中率也比較低，使用Cache不劃算，是以對于這些照片的政策是直接在使用者上傳的時候分發到到圖檔存儲伺服器上，在使用者通路的時候直接進行通路，當然圖檔的位置需要在資料庫中進行記錄，不然找不到放在哪台伺服器上就郁悶了。 五、 Technorati的背景資料庫架構 Technorati (現在被阻尼了, 可能你通路不了)的 Dorion Carroll在 2006 MySQL 使用者會議上介紹了一些關于 Technorati 背景資料庫架構的情況. 基本情況 目前處理着大約 10Tb 核心資料, 分布在大約 20 台機器上.通過複制, 多增加了 100Tb 資料, 分布在 200 台機器上. 每天增長的資料 1TB. 通過 SOA 的運用, 實體與邏輯的通路相隔離,　似乎消除了資料庫的瓶頸. 值得一提的是, 該擴充過程始終是利用普通的硬體與開源軟體來完成的. 畢竟 , Web 2.0 站點都不是燒錢的主. 從資料量來看，這絕對是一個相對比較大的 Web 2.0 應用. Tag 是 Technorati 最為重要的資料元素. 爆炸性的 Tag 增長給 Technorati 帶來了不小的挑戰. 2005 年 1 月的時候, 隻有兩台資料庫伺服器, 一主一從. 到了 06 年一月份, 已經是一主一從, 6 台 MyISAM 從資料庫用來對付查詢, 3 台 MyISAM 用作異步計算. 一些核心的處理方法: 1) 根據實體(tags/posttags))進行分區 衡量資料通路方法，讀和寫的平衡.然後通過不同的次元進行分區．( Technorati 資料更新不會很多, 否則會成為資料庫災難) 2) 合理利用 InnoDB 與 MyISAM InnoDB 用于資料完整性/寫性能要求比較高的應用. MyISAM 适合進行 OLAP 運算. 物盡其用. 3) MySQL 複制 複制資料到從主資料庫到輔資料庫上,平衡分布查詢與異步計算, 另外一個功能是提供備援． 如圖

六、 通過了解MySpace的六次重構經曆,來認識分布式系統到底該如何建立.

在每個裡程碑，站點負擔都會超過底層系統部分元件的最大載荷，特别是資料庫和存儲系統。接着，功能出現問題，使用者失聲尖叫。最後，技術團隊必須為此修訂系統政策。

　　雖然自2005年早期，站點賬戶數超過7百萬後，系統架構到目前為止保持了相對穩定，但MySpace仍然在為SQL Server支援的同時連接配接數等方面繼續攻堅，Benedetto說，"我們已經盡可能把事情做到最好"。

1. 裡程碑一：50萬賬戶

　　按Benedetto 的說法，MySpace最初的系統很小，隻有兩台Web伺服器和一個資料庫伺服器。那時使用的是Dell雙CPU、4G記憶體的系統。

　　單個資料庫就意味着所有資料都存儲在一個地方，再由兩台Web伺服器分擔處理使用者請求的工作量。但就像MySpace後來的幾次底層系統修訂時的情況一樣，三伺服器架構很快不堪重負。此後一個時期内，MySpace基本是通過添置更多Web伺服器來對付使用者暴增問題的。

　　但到在2004年早期，MySpace使用者數增長到50萬後，資料庫伺服器也已開始汗流浃背。

　　但和Web伺服器不同，增加資料庫可沒那麼簡單。如果一個站點由多個資料庫支援，設計者必須考慮的是，如何在保證資料一緻性的前提下，讓多個資料庫分擔壓力。

　　在第二代架構中，MySpace運作在3個SQL Server資料庫伺服器上--一個為主，所有的新資料都向它送出，然後由它複制到其他兩個；另兩個全力向使用者供給資料，用以在部落格和個人資料欄顯示。這種方式在一段時間内效果很好--隻要增加資料庫伺服器，加大硬碟，就可以應對使用者數和通路量的增加。

2. 裡程碑二：1-2百萬賬戶

MySpace注冊數到達1百萬至2百萬區間後，資料庫伺服器開始受制于I/O容量--即它們存取資料的速度。而當時才是2004年中，距離上次資料庫系統調整不過數月。使用者的送出請求被阻塞，就像千人樂迷要擠進隻能容納幾百人的夜總會，站點開始遭遇"主要沖突"，Benedetto說，這意味着MySpace永遠都會輕度落後于使用者需求。

"有人花5分鐘都無法完成留言，是以使用者總是抱怨說網站已經完蛋了。"他補充道。

　　這一次的資料庫架構按照垂直分割模式設計，不同的資料庫服務于站點的不同功能，如登入、使用者資料和部落格。于是，站點的擴充性問題看似又可以告一段落了，可以歇一陣子。

　　垂直分割政策利于多個資料庫分擔通路壓力，當使用者要求增加新功能時，MySpace将投入新的資料庫予以支援它。賬戶到達2百萬後，MySpace還從儲存設備與資料庫伺服器直接互動的方式切換到SAN（Storage Area Network，存儲區域網絡）--用高帶寬、專門設計的網絡将大量磁盤儲存設備連接配接在一起，而資料庫連接配接到SAN。這項措施極大提升了系統性能、正常運作時間和可靠性，Benedetto說。

3. 裡程碑三：3百萬賬戶

　　當使用者繼續增加到3百萬後，垂直分割政策也開始難以為繼。盡管站點的各個應用被設計得高度獨立，但有些資訊必須共享。在這個架構裡，每個資料庫必須有各自的使用者表副本--MySpace授權使用者的電子花名冊。這就意味着一個使用者注冊時，該條賬戶記錄必須在9個不同資料庫上分别建立。但在個别情況下，如果其中某台資料庫伺服器臨時不可到達，對應事務就會失敗，進而造成賬戶非完全建立，最終導緻此使用者的該項服務無效。

　　另外一個問題是，個别應用如部落格增長太快，那麼專門為它服務的資料庫就有巨大壓力。

2004年中，MySpace面臨Web開發者稱之為"向上擴充"對"向外擴充"（譯者注：Scale Up和Scale Out，也稱硬體擴充和軟體擴充）的抉擇--要麼擴充到更大更強、也更昂貴的伺服器上，要麼部署大量相對便宜的伺服器來分擔資料庫壓力。一般來說，大型站點傾向于向外擴充，因為這将讓它們得以保留通過增加伺服器以提升系統能力的後路。

　　但成功地向外擴充架構必須解決複雜的分布式計算問題，大型站點如Google、Yahoo和Amazon.com，都必須自行研發大量相關技術。以Google為例，它建構了自己的分布式檔案系統。

　　另外，向外擴充政策還需要大量重寫原來軟體，以保證系統能在分布式伺服器上運作。"搞不好，開發人員的所有工作都将白費"，Benedetto說。

　　是以，MySpace首先将重點放在了向上擴充上，花費了大約1個半月時間研究更新到32CPU伺服器以管理更大資料庫的問題。Benedetto說，"那時候，這個方案看似可能解決一切問題。"如穩定性，更棒的是對現有軟體幾乎沒有改動要求。

　　糟糕的是，高端伺服器極其昂貴，是購置同樣處理能力和記憶體速度的多台伺服器總和的很多倍。而且，站點架構師預測，從長期來看，即便是巨型資料庫，最後也會不堪重負，Benedetto說，"換句話講，隻要增長趨勢存在，我們最後無論如何都要走上向外擴充的道路。"

　　是以，MySpace最終将目光移到分布式計算架構--它在實體上分布的衆多伺服器，整體必須邏輯上等同于單台機器。拿資料庫來說，就不能再像過去那樣将應用拆分，再以不同資料庫分别支援，而必須将整個站點看作一個應用。現在，資料庫模型裡隻有一個使用者表，支援部落格、個人資料和其他核心功能的資料都存儲在相同資料庫。

　　既然所有的核心資料邏輯上都組織到一個資料庫，那麼MySpace必須找到新的辦法以分擔負荷--顯然，運作在普通硬體上的單個資料庫伺服器是無能為力的。這次，不再按站點功能和應用分割資料庫，MySpace開始将它的使用者按每百萬一組分割，然後将各組的全部資料分别存入獨立的SQL Server執行個體。目前，MySpace的每台資料庫伺服器實際運作兩個SQL Server執行個體，也就是說每台伺服器服務大約2百萬使用者。Benedetto指出，以後還可以按照這種模式以更小粒度劃分架構，進而優化負荷分擔。

　　當然，還是有一個特殊資料庫儲存了所有賬戶的名稱和密碼。使用者登入後，儲存了他們其他資料的資料庫再接管服務。特殊資料庫的使用者表雖然龐大，但它隻負責使用者登入，功能單一，是以負荷還是比較容易控制的。

4. 裡程碑四：9百萬到1千7百萬賬戶

2005年早期，賬戶達到9百萬後，MySpace開始用Microsoft的C#編寫ASP.NET程式。C#是C語言的最新派生語言，吸收了C++和Java的優點，依托于Microsoft .NET架構（Microsoft為軟體元件化和分布式計算而設計的模型架構）。ASP.NET則由編寫Web站點腳本的ASP技術演化而來，是Microsoft目前主推的Web站點程式設計環境。

　　可以說是立竿見影， MySpace馬上就發現ASP.NET程式運作更有效率，與ColdFusion相比，完成同樣任務需消耗的處理器能力更小。據技術總監Whitcomb說，新代碼需要150台伺服器完成的工作，如果用ColdFusion則需要246台。Benedetto還指出，性能上升的另一個原因可能是在變換軟體平台，并用新語言重寫代碼的過程中，程式員複審并優化了一些功能流程。

　　最終，MySpace開始大規模遷移到ASP.NET。即便剩餘的少部分ColdFusion代碼，也從Cold-Fusion伺服器搬到了ASP.NET，因為他們得到了BlueDragon.NET（喬治亞州阿爾法利塔New Atlanta Communications公司的産品，它能将ColdFusion代碼自動重新編譯到Microsoft平台）的幫助。

　　賬戶達到1千萬時，MySpace再次遭遇存儲瓶頸問題。SAN的引入解決了早期一些性能問題，但站點目前的要求已經開始周期性超越SAN的I/O容量--即它從磁盤存儲系統讀寫資料的極限速度。

　　原因之一是每資料庫1百萬賬戶的分割政策，通常情況下的确可以将壓力均分到各台伺服器，但現實并非一成不變。比如第七台賬戶資料庫上線後，僅僅7天就被塞滿了，主要原因是佛羅裡達一個樂隊的歌迷瘋狂注冊。

　　某個資料庫可能因為任何原因，在任何時候遭遇主要負荷，這時，SAN中綁定到該資料庫的磁盤儲存設備簇就可能過載。"SAN讓磁盤I/O能力大幅提升了，但将它們綁定到特定資料庫的做法是錯誤的。"Benedetto說。

　　最初，MySpace通過定期重新配置設定SAN中資料，以讓其更為均衡的方法基本解決了這個問題，但這是一個人工過程，"大概需要兩個人全職工作。"Benedetto說。

長期解決方案是遷移到虛拟存儲體系上，這樣，整個SAN被當作一個巨型存儲池，不再要求每個磁盤為特定應用服務。MySpace目前采用了一種新型SAN裝置--來自加利福尼亞州弗裡蒙特的3PARdata。

　　在3PAR的系統裡，仍能在邏輯上按容量劃分資料存儲，但它不再被綁定到特定磁盤或磁盤簇，而是散布于大量磁盤。這就使均分資料通路負荷成為可能。當資料庫需要寫入一組資料時，任何空閑磁盤都可以馬上完成這項工作，而不再像以前那樣阻塞在可能已經過載的磁盤陣列處。而且，因為多個磁盤都有資料副本，讀取資料時，也不會使SAN的任何元件過載。

　　當2005年春天賬戶數達到1千7百萬時，MySpace又啟用了新的政策以減輕存儲系統壓力，即增加資料緩存層--位于Web伺服器和資料庫伺服器之間，其唯一職能是在記憶體中建立被頻繁請求資料對象的副本，如此一來，不通路資料庫也可以向Web應用供給資料。換句話說，100個使用者請求同一份資料，以前需要查詢資料庫100次，而現在隻需1次，其餘都可從緩存資料中獲得。當然如果頁面變化，緩存的資料必須從記憶體擦除，然後重新從資料庫擷取--但在此之前，資料庫的壓力已經大大減輕，整個站點的性能得到提升。

　　緩存區還為那些不需要記入資料庫的資料提供了驿站，比如為跟蹤使用者會話而建立的臨時檔案--Benedetto坦言他需要在這方面補課，"我是資料庫存儲狂熱分子，是以我總是想着将萬事萬物都存到資料庫。"但将像會話跟蹤這類的資料也存到資料庫，站點将陷入泥沼。

　　增加緩存伺服器是"一開始就應該做的事情，但我們成長太快，以緻于沒有時間坐下來好好研究這件事情。"Benedetto補充道。