原地址：http://www.cnblogs.com/gaizai/archive/2010/01/04/1638325.html
?
2010.01.03，今天開始看這本書，剛看了第一章就已經(jīng)有了共鳴的感覺，可能是因為我之前有過兩個性能優(yōu)化項目的經(jīng)驗吧，其實感覺最重要的一點就是在第二個項目優(yōu)化的過程中刻意去做一些總結(jié)，希望接下來的閱讀會有更多這個的共鳴出現(xiàn)。（期待中。。。）
網(wǎng)絡(luò)上沒有這本書的電子版，只有兩章的免費試讀， 進入試讀地址 ，唉，真不知道以后要像這樣引用文章該如何辦啊？！
下面是在閱讀過程中感覺比較重要的內(nèi)容，并加入了自己的一些體會：
?
【1】出現(xiàn)的一個名詞“平行運算”，SQL的平行運算
平行運算 又名 并行計算（Parallel Computing）
并行計算（Parallel Computing）是指同時使用多種計算資源解決計算問題的過程。為執(zhí)行并行計算，計算資源應(yīng)包括一臺配有多處理機（并行處理）的計算機、一個與網(wǎng)絡(luò)相 連的計算機專有編號，或者兩者結(jié)合使用。并行計算的主要目的是快速解決大型且復(fù)雜的計算問題。此外還包括：利用非本地資源，節(jié)約成本 ― 使用多個“廉價”計算資源取代大型計算機，同時克服單個計算機上存在的存儲器限制。
?
【2】性能調(diào)優(yōu)需要哪些技能
? 體會：還是比較贊同這些知識結(jié)構(gòu)的，我們要有目的地學(xué)習(xí)這幾個方面的知識，打開視野，對調(diào)優(yōu)也是有好處的。?
?
【3】摘要：
?? 體會：以前一直認(rèn)為優(yōu)化知識修改幾個代碼里面的循環(huán)語句，修改幾條SQL語句（把批量的數(shù)據(jù)庫操作修改成類似于Insert Select等）就能了事了，雖然這樣成功優(yōu)化了兩個系統(tǒng)（并沒有完全優(yōu)化，只是做研究或者叫練手，因為要求并不高，只要能比以前有大的性能改進就可以 了），但是一直沒有想過string與StringBuilder也會有這么大的性能問題，而且網(wǎng)上已經(jīng)有很多人討論這個問題，而我卻沒有關(guān)注過，慚愧 啊，所以.Net的知識也需要加深啊。
?
【4】摘要：
整個應(yīng)用程序的開發(fā)最好先快速建立測試系統(tǒng)（prototype），讓用戶在開發(fā)程序中一再測試，以循環(huán)遞增的方式屢次修正問題，提早發(fā)現(xiàn)潛藏的性能問題，在開發(fā)程序中解決性能問題要比系統(tǒng)完成，交付后才發(fā)現(xiàn)性能問題，而后需要大改來得好。
? 體會：對使用視圖我并不完全贊同，視圖是可以降低系統(tǒng)的耦合，也有效的對表字段進行了權(quán)限控制，我們平常使用視圖的主要目的就是聯(lián)合多個表，方便查詢；但是這樣的話，表中的索引如何有效地使用呢？
即使SQL Server2005可以對視圖進行索引，但是也有缺點，第一個是不方便，有限制；第二，如果視圖比較大，索引造成磁盤空間會大大增大；
有時可以考慮使用存儲過程，這樣就可以使用表的索引了，又可以對字段進行控制，也可以比較大的解耦，又可以有執(zhí)行緩存，貌似這個方案不錯，但是 如果什么都靠存儲過程，第一很容易就有存儲過程風(fēng)暴；第二對分頁支持不太好；第三，我們的程序的邏輯變化會比較大，寫存儲過程對業(yè)務(wù)邏輯的維護比較麻煩。
有時遇到大的邏輯處理，我們會把一些必要的數(shù)據(jù)先查詢出來，在進行編碼邏輯處理，在進行組裝，生成一個邏輯數(shù)據(jù)。所以我們要根據(jù)不同的需求來確定使用方法。
?
【5】性能基線
·昔日系統(tǒng)正常運行時的數(shù)據(jù)。
·調(diào)校前系統(tǒng)的各種數(shù)據(jù)。
·用戶希望達(dá)到的目標(biāo)。
基線是用來比較的，任何性能調(diào)校的動作都應(yīng)該依憑數(shù)據(jù)，不要訴諸情緒。
? 體會：在優(yōu)化公司的第二個項目的時候就自己感悟到基線了，所以這點我也是很贊同的，是一個性能測試和優(yōu)化的前期需要做的工作。
因為有了基線才好做對比，做比較，也才會有成就感。
?
【6】摘要
·用戶苦等一兩個月，最后還是換機器，他們會覺得工程師能力不足。
·實際上浪費了人力成本。
·一陣子后，性能問題又再度浮現(xiàn)。
? 體會：事前的整體評估很重要，關(guān)系到成本和各戶交互中的重要作用。
?
【7】摘要：
嘗試列出系統(tǒng)中各個組件合理的性能消耗，可以幫助你理清整個系統(tǒng)訪問中，各個組件所占的性能消耗比例，哪些部分有可以調(diào)整的空間。另外，再搭配調(diào)整該部分的成本有多高，讓你了解調(diào)整的優(yōu)先級，并對系統(tǒng)的極限有更佳的認(rèn)識。
? 體會：對這段描述是比較贊同的。
這也得從優(yōu)化公司的第二個項目說起，那個時候就做了比較多的前期工作，比如測試、基線、文檔、分析、猜想、評估等工作，最后的優(yōu)化就花了一天的時間，雖然還沒有優(yōu)化全部的內(nèi)容，但是性能還是有了很大的提高的。
優(yōu)化后的總結(jié)也是很重要的，可以把優(yōu)化過程記錄下來，沉淀一些知識，這次我就總結(jié)出一個比較通用的優(yōu)化流程，改天帖出來。
?
【8】摘要
現(xiàn)將各步驟的原文列出如下：
Discover?the?problem：發(fā)現(xiàn)問題。
Explore?the?conditions：探究原因，為問題提供明確的定義與定位。
Track?down?possible?approaches：提供可能的解決方案。
Execute?the?most?likely?approach：執(zhí)行最有可能的解決方案。
Check?for?success（如果需要的話，重復(fù)之前的步驟）：確認(rèn)解決方案成功與否。
Tie?up?loose?ends：完成收尾的工作。
? 體會：<1>：這才發(fā)現(xiàn)我之前一個項目的優(yōu)化步驟和這個有80%的相似度（在看這本書之前），這讓我小小開心了一下。
<2>：這再一次證明了我的觀點：在開始學(xué)一些新知識的時候，一定要先自己動手去嘗試，不要一開始就買一個《XX入門》之類的書籍來看。
<3>：需要注意一點就是，在接下來的實踐中，有意識的去看看文中的描述是否可以借鑒，通過這樣的方式來完善自己的那套調(diào)優(yōu)步驟。
?
【9】摘要
確定用戶的問題與需求后，下一步是探究原因，此步驟的重點是“探索（Explore）”、“找尋證據(jù)（Evidence）”、“建立（Establish）”描述整個問題來龍去脈的假設(shè)。
當(dāng)你從以上步驟確切了解用戶的問題后，就需要建立問題發(fā)生原因的假設(shè)和導(dǎo)致性能不足的運行模型，而當(dāng)前這個步驟便是在搜集證據(jù)，以建立并確認(rèn)該假設(shè)。在 這個階段中，你可以通過SQL?Server?Management?Studio、SqlDiag.exe、性能計數(shù)器、事件查看器、 SQL?Profiler、SQL?Server?2005?Performance?Dashbord?Reports、DMV與DMF等工具來找線索 （以上工具在本書第3章“性能調(diào)校相關(guān)工具程序”中有詳細(xì)說明）。
這個步驟的主要任務(wù)是廣泛搜集相關(guān)數(shù)據(jù)，但并未深入分析數(shù)據(jù)間的關(guān) 聯(lián)性，這是下一步驟要做的事情。當(dāng)然，要搜集正確而相關(guān)的證據(jù)，難免要稍做分析，但不要過度耗時在某項單一的事件上。此步驟要的是全貌，盡量了解系統(tǒng)的每 一個方面，避免深入分析時，漏了某個關(guān)鍵現(xiàn)象而誤入歧途。
當(dāng)然，若在這個階段就發(fā)現(xiàn)重大問題，一眼就看出關(guān)鍵點，例如，硬件毀損，某 個硬盤區(qū)間或內(nèi)存區(qū)間不穩(wěn)，某個程序吃掉所有的內(nèi)存，讓SQL?Server無內(nèi)存可用，抑或是該程序常常出問題，拖垮CPU等，則可以跳過DETECT 方法論之后的步驟，進行深入探討這個問題并予以解決。
通常性能調(diào)校并不是那么容易一眼看出重大錯誤，或許用戶自己就可以解決，而需要 專門做性能調(diào)校的情況可能如戰(zhàn)場上不斷帶來的傷患，第一步要做的是決定傷患的輕重，再決定如何利用有限的資源做最有效的治療。當(dāng)你在前一步獲得用戶大量的 問題后，接下來就要搜集并探究各種現(xiàn)象，決定輕重緩急，通盤考慮后，進入下一步。
? 體會：摘取這段是有目的的，它說明了幾個知識點：
第一，建立假設(shè)命題；
第二，可以看到性能的檢測使用了那些工具；
第三，并不深入分析，稍作分析，不耗時在某個問題上；
第四，決定輕重緩急；第五，對一眼就能看出問題予以解決。（個人補充：不過要回去證明，也就是狹義上的回歸測試）
?
【10】摘要
二分法的局限
·二分查找算法的局限是數(shù)據(jù)必須要有順序才能做二分查找。同樣地，你對于系統(tǒng)的知識要具備廣泛的連續(xù)性，才能在問題發(fā)生時，分析問題所在的位置。
·第二個局限是你無法知道是否不小心把問題隔離在目標(biāo)區(qū)域以外了，只好從頭再來，這樣會讓你喪失信心。
·最后一個局限性，也是最大的問題所在：某些性能問題不單純地以本來的面目呈現(xiàn)，因此分解問題時，可能會被現(xiàn)象蒙蔽。
? 體會：這一段入選的原因就是：在我的頭腦里面就沒有調(diào)優(yōu)可以使用“二分查找”這樣的概念，雖然文中也說了一些缺點，但是有機會我還是會去嘗試一下，看看是否有道理的，不過估計希望不大。
?
【11】摘要
前5個步驟循環(huán)重復(fù)地執(zhí)行，每一次循環(huán)的結(jié)果都更逼近問題的核心，直到達(dá)到性能調(diào)校的目標(biāo)。
但當(dāng)我們完成目標(biāo)后，依然要注意以下的問題：
·解決的方式是否有邊際效應(yīng)而造成其他的問題？
例如，為了某類的查詢工作建立了大量的索引，事后原本正常的添加、修改、刪除都出現(xiàn)了性能問題。
·是否真正根除了問題，還是僅表象地頭痛醫(yī)頭，腳痛醫(yī)腳？
建立問題的假設(shè)時，很容易將問題特殊化，僅局部地解決該問題。例如，加了某個索引或稍稍改變查詢語句，舒緩了當(dāng)前的瓶頸，但當(dāng)用戶稍微增加或采用不同的查詢方式時，老問題就容易復(fù)發(fā)。
·是否要建立持續(xù)跟蹤的計劃？
當(dāng)你無法確定已經(jīng)根除問題時，那可能就要擬定持續(xù)跟蹤的計劃了。決定是否要持續(xù)觀察某些計數(shù)器，跟蹤某些現(xiàn)象是否還會發(fā)生，若發(fā)生了要如何解決等。如此不但可以讓用戶安心，更可以讓你知道之前的行為到底有多少效益，下次的性能調(diào)校才能提出更完整的解決方案。
? 體會：這里說到的幾點可能是我們平時會忽略的問題，感覺第一點最重要了。比如在調(diào)優(yōu)的過程中發(fā)現(xiàn)是代碼的問題，那么在修改代碼的過程就會對原 來邏輯進行修改（例如原來是對數(shù)據(jù)庫進行循環(huán)操作造成的性能問題，那么調(diào)優(yōu)方案就可能是進行批量操作數(shù)據(jù)），這種時候就無形中修改了原來的邏輯，這個時候 我們要對新的邏輯進行必要的測試，其中包括功能測試和性能測試。
?
【12】對上面Detect方法的總結(jié)：
·對問題的簡單描述；
·建立基線；
·假設(shè)（個人術(shù)語：猜想）；
·決定輕重緩急；
·假設(shè)問題的計劃，解決問題的計劃；
·驗證假設(shè)；
·擬定新的計劃；
·到底有多少效益；
?
【13】調(diào)優(yōu)基本流程圖
?
?
【14】“ 華麗的總結(jié) ”
性能調(diào)優(yōu)的核心思想：就像中學(xué)的時候，給自己出一個命題，自己再去證明這個命題。（呵呵，很生動吧。O(∩_∩)O~）
?
更多文章、技術(shù)交流、商務(wù)合作、聯(lián)系博主
微信掃碼或搜索：z360901061
微信掃一掃加我為好友
QQ號聯(lián)系： 360901061
您的支持是博主寫作最大的動力，如果您喜歡我的文章，感覺我的文章對您有幫助，請用微信掃描下面二維碼支持博主2元、5元、10元、20元等您想捐的金額吧，狠狠點擊下面給點支持吧，站長非常感激您！手機微信長按不能支付解決辦法：請將微信支付二維碼保存到相冊，切換到微信，然后點擊微信右上角掃一掃功能，選擇支付二維碼完成支付。
【本文對您有幫助就好】元
