第1 用戶經過網絡取得信息。

　　在剛著手，網絡上頭的信息比較少，那末用戶只消記取幾個站點就可以了。而隨著網絡內部實質意義的增加，信息量越來越大，用戶取得所需求的信息，成本越來越高。這時，技術的變法，搜索引擎網站的顯露出來，增長了用戶取得信息的速率，這算的上是，運用更好的算法，來增長執行速率。而當面對搜索更多私人信息時，需要萌生了變動，這時傳統的搜索引擎網站就不可以了。一種新的技術隨之顯露出來，人肉搜索。

　　第二 在系統部署方面。

　　在信息化時期剛著手時，公司所用的軟件還較小，開始的花銷比較低，保護成本也很低，因為這個普通都是把軟件買歸來，自個兒安裝和保護。但當用戶運用的軟件系統越來越大時，開始的一段時間成本和保護成本越來越高，公司載荷越來越大，這時需求優化。雲計算適合時宜而出，其將用戶所運用的軟件集中起來，放在核心保護，而用戶則依據軟件運用付費。這個標准樣式和Linux下進程項十分相像，在Linux中進程項的代碼段內存是共享的，數值段等則每個進程項一個。我們可以把公司類比成一個個進程項，雲計算類比成將各個進程項公用的代碼段，以資來增長速率。

　　第三 為何軟件性能會越來越低。

　　在剛著手預設完成，手續的性能或許是好的，但當需要的不斷增加，代碼的改動，手續的性能卻越來越慢。這處面有幾個端由，需要變動時，我們不是去思索問題軟件在思維規律上怎麼更加合理，而是怎麼在現存代碼上改動更加便捷，這就造成代碼隨著需要變動，手續的思維規律越來越不符合理，萌生了偏移。

　　額外，當需要變動時，有點case已經不再會運行到達，這時我們往往不會去刪去相應的思維規律，由於其可能造成不正確。對於需要變動，我們更願意往上頭加物品，而不是減物品。這就造成了代碼越來越極大，並且眾多都是無用的代碼。軟件這麼，我們平時中的流程一樣這麼。譬如說bug管理系統，有一天某個上層要求計數一下子數值，這時他要求手續在錄入bug時加上一個字段。可過了時期，上層不在要這個數值了，往往程序開發人員還在接著多輸入這樣一個字段。

　　第四， 速率的增長，或許並不必非常大的辦公量。

　　仍然以bug管理來講，普通我們都是經過網站的形式來seo管理bug的，每個程序開發人員都需求不斷的去網站上按F5，來看是否有新的bug。這麼一個程序開發人員對於bug的迅速響應，就要看其按F5bug系統頁面的頻率了。假如其半晌查問一次，那末其可能耗費半晌的時間。可是假如我們讓bug網站該程序開發人員一有bug，就給該程序開發人員送出一封郵件的話，如果用戶的郵件是實時開著的，況且每個5分鍾查問一下子信箱，那末我們就可以保證程序開發人員對於bug的響應時間縮減到5分鍾。網站上加個郵件功能很容易，但其卻很可能會大規模的增長速率。速率的增長與優化所消耗的錢的effor並不盡然成正比，關鍵是你找對地方。