本節書摘來自異步社群《應用程式性能測試的藝術（第2版）》一書中的第1章，第1.2節為什麼性能問題如此常見，作者【紐西蘭】ian molyneaux（莫得尼克斯），更多章節内容可以通路雲栖社群“異步社群”公衆号檢視。
1.2 為什麼性能問題如此常見
上文為什麼是好的性能、什麼是差的性能做了一個基本的定義。應用的性能孰優孰劣，似乎也很好判斷，那為什麼還有那麼多的應用無法滿足高性能這樣一個關鍵需求呢？下文給出了一些常見的原因。
1.2.1 it商業價值曲線
性能問題之是以讓人頭疼，有一個很重要的原因就是它通常在應用生命周期的後期才會凸顯出來，越晚發現問題，就要花費越多的精力去解決問題。圖1-1所示的it商業價值曲線很好地描述了這個觀點。
圖1-1所示中，實線（預期）表示在經過一段時間的it投入（應用開發過程）後，應用按期釋出成功，上線之後運作良好，幾乎沒有任何性能問題，并立即開始帶來營收（黑色方塊）。
圖1-1所示中，虛線（實際）描繪了在現實世界經常發生的真實情況：開發延遲、釋出延期（虛線方塊）。應用釋出上線之後，為了應對層出不窮的線上性能問題，大量的時間和金錢被消耗。最終開發出來的應用不能為企業帶來預期的收益，這對誰都不是一個好消息。
類似這樣的問題，在公司董事執行層得到越來越多的重視。很多公司都引入了it服務管理（information technology service management，itsm）和it資産管理（information technology portfolio management，itpm），希望由此走上擁抱it基礎架構庫（information technology infrastructure library，itil）這個行業标準的道路。在當今很多公司裡，it部門再也不是一個“獨立王國”，可以享受不受限制的資金和資源投入。它也成為公司衆多部門當中的一個（重要的）業務單元，同樣需要在一定的預算控制下運作。
1.2.2 性能測試成熟度
圖1-2所示是弗雷斯特研究公司在2006年針對一次應用部署的産品中性能缺陷的修複率監控得到的資料。在本次再版中，我本想用一些更新的資料來代替這張圖，但是很遺憾，這些資料從2009年以來似乎并沒有發生太大變化。
圖1-2中描述了3個性能測試成熟度等級。第一級稱為“救火式”，也就是說在應用正式釋出之前幾乎沒有任何性能測試，是以基本上所有的性能問題都需要線上上發現并解決。這是最低效的一種方式，但讓人詫異的是，這種做法在業界還相當普遍。采用救火式對待應用性能的公司面臨着巨大的風險。
第二級稱為“性能驗證（或者叫檢驗）”。采用這種模式的公司在對待應用性能時，會做一些性能測試，但是這通常隻會發生在應用生命周期的靠後階段；是以，仍然會有相當一部分性能缺陷會遺漏到線上（30%）。這是目前大多數公司采用的方式。
最後一級稱為“性能驅動”。這意味着在應用生命周期的每一個階段，性能都會被納入考慮。采用這種方式的公司，通常隻會有很小一部分性能缺陷遺漏到線上（5%）。這才是所有公司應該努力采用的一種性能測試模式。
1.2.3 在應用設計階段缺少性能考慮
回到關于導緻性能問題的常見原因的讨論上來：如果在應用設計階段沒有充分考慮性能，麻煩會接踵而至。“性能驅動設計”本身對于應用性能就是一個很好的保證，或者至少在出現意料之外的性能問題時，提供了一種便捷修複的可能性。由于設計導緻的性能問題如果在應用生命周期的早期階段沒有發現，那麼到後期很難徹底消除，而且這種性能糾正如果不耗費巨大返工幾乎是不可能的。
1.2.4 最後一刻才想起性能測試
上文提到，有很多公司在研發過程中采用了“性能驗證/檢驗”模式。使用這種模式，性能測試往往是在應用即将釋出之前才開始的，他們幾乎沒有考慮性能測試本身所需要的時間，也沒有考慮如果發現問題所需要的修複時間。雖然這種方式比性能“救火”要好，但這種方式的缺點也顯而易見：一些非常嚴重的性能缺陷仍有可能被遺漏到線上；另一種情況是雖然發現了問題，但是卻沒有足夠的時間在應用釋出以前修複這些問題。
性能測試被延遲到最後一刻帶來的常見場景就是為了修複臨近釋出才發現的性能問題，應用釋出不得不一拖再拖。一個帶着性能問題上線的應用在釋出之後仍需要不斷的投入來修複問題，最壞的情況是應用徹底下線直到問題解決。
所有這些問題都會對業務以及等着使用應用的客戶信心造成極大的負面影響。是以性能測試必須盡早開始，而不是等到應用即将釋出的最後一刻。
1.2.5 可擴充性
對應用容量需求或者應用的可擴充性評估不足也是導緻性能問題常見的一個原因。應用的設計和預期的釋出模式很容易忽視潛在的使用者社群體量和地理分布。許多應用在開發和測試過程中都容易忽略下面一些問題。
有多少終端使用者會使用這個應用？
這些使用者會分布在什麼地方？
有多少使用者會并發使用這個應用？
終端使用者如何接入這個應用？
随着時間發展，應用的使用者增長模式是怎樣的？
最終的應用拓撲是怎樣的，會有多少台伺服器，它們地理位置分布在哪裡？
應用對于網絡容量的需求會是怎樣的？
如果忽視上面提到的這些問題，我們就無法真實評估應用到底需要支援多少線上并發使用者。同樣，應用終端使用者的網絡情況，比如低帶寬、高延遲的廣域網連接配接，也是容易被忽視的一個考量因素。本書第2章将會讨論關于連接配接性問題的更多細節。
1.2.6 低估受歡迎程度
很多公司會低估他們網站的受歡迎程度，這聽起來有點奇怪，但是事實确實如此。公司在釋出網站時容易忽視“追新效應”。每當有什麼新奇的東西出現，人們都會對此非常好奇，然後蜂擁而至。有的時候為了釋出效果，公司也會通過媒體來做一些推廣，這就更加重了這種群集效應：本來預期網站在釋出之後第一天會有10000的點選量，結果等着你的卻是1000000的點選量，這樣預期之外的壓力足以将你的系統徹底擊潰。
換句話說，當我們考慮性能時，我們需要考慮的是峰值流量而不是平峰流量。
重大故障：一個真實案例
幾年前，英國政府決定在網際網路上公開1901年的人口普查資料。這項工程浩大，需要将大量的紙質文檔電子化，然後開發一個應用供使用者來通路。
我本人也非常期待這個項目的實施，因為我當時正在追溯自己的家族曆史，而政府即将公開的這部分資料應該可以提供很多有用的資訊。當這個網站上線之後，我便馬上登入使用。雖然我發現網站有點慢，但我還是能夠用它進行一些簡單的搜尋。然後僅僅過了一天，當我再來使用這個網站時，呈現在我面前的已經是一則道歉資訊，表明網站暫時不可用。這個網站在最終修複重新釋出之前連續好幾個星期不可用。
這是一個低估應用受歡迎程度的典型案例。大家對這個網站的關注程度遠遠超出了預期，是以網站的性能支撐不了如此大體量的通路點選。這并不意味着這個網站在推出之前沒有做過性能測試。但這個案例至少說明，對于這樣一個網站，評估的性能和容量需求太保守了。
一個好的應用必須能夠支撐那些突發的需求高峰。
1.2.7 性能測試還是一門非正式學科
正如上文提到的那樣，性能測試計劃和實施通常還是非常不正式的。其中的原因很難考究，因為功能測試在很多年前就已經成為一門非常正式的學科。關于功能測試，行業内有許多沉澱和專家意見，甚至還有很多咨詢公司專門提供測試類的咨詢服務。
回到2009年看性能測試，情況卻和功能測試恰恰相反，至少從參考資料的層面上說是這樣。當時測試行業内幾乎沒有任何關于性能測試的系統性文檔，是以我決定為性能測試寫些東西。我們一直不缺關于如何進行應用性能調優的書籍和文檔，但是闡述如何有效地進行性能測試的書籍實在是太少了。
到了2014年，我很高興地看到情況有所改觀。當我們在谷歌上搜尋“性能測試”的時候，我們能夠搜到大量公司，他們提供性能測試服務、工具和一些教育訓練，當然這些公司更多的出發點還是性能測試工具。
1.2.8 沒有使用自動化測試工具
如果不使用自動化工具，就沒有辦法有效開展性能測試。人肉戰術（周末叫上100個心懷怨恨的員工，掐着秒表測試性能）顯然不是一個好主意。首先，這種人肉測試沒法複用，然後為了測試穩定性，讓員工連續24小時使用/測試系統，這恐怕已經侵犯員工權利了。
還有，你如何對來自100個不同員工的響應時間資料進行關聯分析呢？更别提還有那麼多監控名額（網絡、伺服器）需要關注。如果你的應用的目标使用者數小于5個，這種人肉性能測試方法或許還可行，但是如果真是這樣，恐怕你現在也不需要閱讀這本書了。
業界有不少非常棒的性能測試工具，而且這樣的工具還會越來越多。需要進行多大規模的性能測試，很大程度上決定了你使用工具的成本。好消息是，性能測試工具市場是一個充滿競争的市場，最大的不一定是最好的。是以在選擇工具之前，最好多做點功課，幫助公司it預算負責人更好地決策。附錄c的清單包含了當今業内領先的性能測試工具供應商。第2章會詳細講述如何根據需求，選擇最合适的性能測試工具。
1.2.9 應用技術的影響
應用開發中使用到的一些技術，可能無法使用第一代，甚至第二代自動化工具來進行壓測。這樣的借口已經越來越勉強了，因為如今絕大多數的應用都在一定程度上web化了。而如今大部分自動化測試方案都能夠很好地支援web技術。
web軟體開發過程中的技術棧都慢慢開始标準化了，形成了一些核心的技術。大多數自動化工具供應商都會跟随這個節奏，推出對應支援功能。在本書第9章，我會探讨一下現在（以及老舊）的應用技術如何影響了性能測試的發展。