The Will Will Web

ApacheBench 工具程式是 Apache 網站伺服器軟體的一個附帶的工具軟體，專門用來執行網站伺服器的運行效能，特別是針對 Apache 網站伺服器 的效能分析。這支程式原本是用來檢測 Apache 網站伺服器(Web Server) 所能夠提供的效能，特別是可以看出 Apache 網站伺服器能提供每秒能送出多少網頁，當然的，也可以用在任何其他的網站伺服器，例如說：IIS 或 lighttpd。

你可以到 Apache HTTP Server 網站下載最新版，如果你要在 Windows 的環境執行 ApacheBench 可以直接下載 Win32 Binary 的版本就好，由於線上所提供的版本是 MSI 的封裝檔，安裝好之後也等同於在你的電腦內安裝了一套 Apache HTTP Server，如果你不需要多執行一套 Apache HTTP Server 的話，你可以在安裝好之後進入 C:\Program Files\Apache Group\Apache2\bin 目錄，找到 ab.exe 執行檔，複製出來後再移除 Apache 安裝即可，因為 ab.exe 是可以獨立執行的，不需要任何關連的 dll 檔。

底下是 ab.exe 的使用參數摘要說明，若要看詳細說明可以看這裡（或中文翻譯）：

C:\>ab -h
Usage: ab [options] [http://]hostname[:port]/path
Options are:
    -n requests     Number of requests to perform
    -c concurrency  Number of multiple requests to make
    -t timelimit    Seconds to max. wait for responses
    -p postfile     File containing data to POST
    -T content-type Content-type header for POSTing
    -v verbosity    How much troubleshooting info to print
    -w              Print out results in HTML tables
    -i              Use HEAD instead of GET
    -x attributes   String to insert as table attributes
    -y attributes   String to insert as tr attributes
    -z attributes   String to insert as td or th attributes
    -C attribute    Add cookie, eg. 'Apache=1234. (repeatable)
    -H attribute    Add Arbitrary header line, eg. 'Accept-Encoding: gzip'
                    Inserted after all normal header lines. (repeatable)
    -A attribute    Add Basic WWW Authentication, the attributes
                    are a colon separated username and password.
    -P attribute    Add Basic Proxy Authentication, the attributes
                    are a colon separated username and password.
    -X proxy:port   Proxyserver and port number to use
    -V              Print version number and exit
    -k              Use HTTP KeepAlive feature
    -d              Do not show percentiles served table.
    -S              Do not show confidence estimators and warnings.
    -g filename     Output collected data to gnuplot format file.
    -e filename     Output CSV file with percentages served
    -h              Display usage information (this message)

而我經常使用的參數摘要如下：

1. 同時 10 個連線，連續點擊 10000 次 ( 每個 Request 執行完畢後都會自動斷線，然後再重新連線 )

ab -n 10000 -c 10 http://www.example.com/index.aspx

ab -n 10000 -c 10 -k http://www.example.com/index.aspx

3. 將測試的效能原始資料匯出成 CSV 檔

ab -e output.csv -n 10000 -c 10 http://www.example.com/index.aspx

   匯出的 output.csv 內容如下：

Percentage served,Time in ms
0,6.200000e+001
1,6.200000e+001
2,6.200000e+001
3,6.200000e+001
4,6.200000e+001
5,6.200000e+001
6,6.200000e+001
7,6.200000e+001
8,6.200000e+001
9,6.200000e+001
10,6.200000e+001
11,6.200000e+001
12,6.200000e+001
13,6.200000e+001
14,6.200000e+001
......

   上表所代表的每一列代表送出的百分比，第二個欄位是當下的 "Time per request" (每個要求所花費的時間)，單位是豪秒(millisecond)。

如何有效的檢視結果

壓力測試的核心在於如何分析結果，底下我用一個測試的結果說明每個欄位所代表的意義。如果你只要看重點的話，可以看 Failed requests、Requests per second、與 Time per request 這三個參數也就差不多夠了。其中的 Failed requests 的數量太高的話，很有可能代表你的 Web Application 的穩定度不夠，而導致使用大量要求時無法回應需求 。而 Request per second 代表你每表可送出的回應數有多少，代表你 Web Application 的承載量有多少（在不考慮頻寬限制的情況下）。

C:\>ab -d -e a.csv -v 1 -n 1000 -c 3 http://www.example.com/index.aspx
This is ApacheBench, Version 2.0.41-dev <$Revision: 1.121.2.12 $> apache-2.0
Copyright (c) 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Copyright (c) 2006 The Apache Software Foundation, http://www.apache.org/

Benchmarking www.m-taoyuan.tw (be patient)
Completed 100 requests
Completed 200 requests
Completed 300 requests
Completed 400 requests
Completed 500 requests
Completed 600 requests
Completed 700 requests
Completed 800 requests
Completed 900 requests
Finished 1000 requests


Server Software:        Microsoft-IIS/6.0
Server Hostname:        www.m-taoyuan.tw
Server Port:            80

Document Path:          /index.aspx
Document Length:        25986 bytes

Concurrency Level:      3
Time taken for tests:   25.734375 seconds
Complete requests:      1000
Failed requests:        0
Write errors:           0
Total transferred:      26372000 bytes
HTML transferred:       25986000 bytes
Requests per second:    38.86 [#/sec] (mean)
Time per request:       77.203 [ms] (mean)
Time per request:       25.734 [ms] (mean, across all concurrent requests)
Transfer rate:          1000.72 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    1   4.4      0      15
Processing:    62   75   9.1     78     109
Waiting:       46   64   8.0     62     109
Total:         62   76   9.3     78     109

如上表顯示的結果來說明，我一個欄位一個欄位的講解如下：

• Server Software:    Web主機的作業系統與版本(若Web主機設定關閉此資訊則無)
• Server Hostname:  Web主機的IP位址(Hostname)
• Server Port:           Web主機的連接埠(Port)
• Document Path:     測試網址的路徑部分
• Document Length: 測試網頁回應的網頁大小
• Concurrency Level: 同時進行壓力測試的人數
• Time taken for tests: 本次壓力測試所花費的總秒數
• Complete requests: 完成的要求數(Requests)
• Failed requests:      失敗的要求數(Requests)
• Write errors:           寫入失敗的數量
• Total transferred:   本次壓力測試的總數據傳輸量(包括 HTTP Header 的資料也計算在內)
• HTML transferred:  本次壓力測試的總數據傳輸量(僅計算回傳的 HTML 的資料)
• Requests per second: 平均每秒可回應多少要求
• Time per request:  平均每個要求所花費的時間(單位: 豪秒)
• Time per request:  平均每個要求所花費的時間，跨所有同時連線數的平均值(單位: 豪秒)
• Transfer rate:         從 ab 到 Web Server 之間的網路傳輸速度

最後的 Connection Times (ms) 指的是壓力測試時的連線處理時間：

橫軸欄位的部分：

• min:       最小值
• mean:    平均值(正、負標準差)
• median: 平均值(中間值)
• max:      最大值

縱軸欄位的部分：

• Connect:     從 ab 發出 TCP 要求到 Web 主機所花費的建立時間。
• Processing:  從 TCP 連線建立後，直到 HTTP 回應(Response)的資料全部都收到所花的時間。
• Waiting:       從發送 HTTP 要求完後，到 HTTP 回應(Response)第一個 Byte 所等待的時間。
• Total:           等於 Connect + Processing 的時間（因為 Waiting 包含在 Processing 時間內了）

壓力測試的基本觀念

• 排除頻寬的限制
  • 做壓力測試通常不會考量「頻寬的限制」，所以一般來說不會將測試的主機擺在遠端機房、然後測試程式擺在公司內部的主機，而是會將壓力測試的 Client 跟 Web 主機擺在同一個網段下進行壓力測試。
  • 因為「頻寬」只要花錢就會有了，但是主機的承載量卻是有限的，從遠端進行壓力測試主要的限制是在「頻寬」而非「效能」，所以從遠端單點進行壓力測試毫無任何意義可言，這樣是測不出主機的效能極限的。
  • 如果你有能力與資源進行大規模（多點）壓力測試的話，透過遠端進行壓力測試才有意義。
• 壓力要循序漸進
  • 你不要一下字就執行同時連線數 100 人，而是要循序漸進的慢慢加同時連線數上去，才不會讓 Web Application 一下字承受過大的負載而導致效能的數據不正確（例如說 Failed requests 過高），但這只是建議，你也可以一下子操死你的主機，反正你在測主機的極限嘛！

參考網址：

• ApacheBench
• ab - Apache HTTP server benchmarking tool
• ab - Apache HTTP服务器性能测试工具 (簡體中文 GB2312 編碼)

我想 FTP 可能有人每天都在用，但卻很少人知道 FTP 運作原理，更尤其是在連不上 FTP 的時候常常都是一頭霧水，在問別人時也可能會發現有人可以連、有人不能連，有的人連的上可以登入成功但是卻無法列出檔案清單，種種的問題只要能了解 FTP 的運作原理就可以很輕易的了解問題出在哪裡，進而解決問題。

基本觀念

使用 FTP 傳輸時，至少會使用到兩個 Port 來建立連線通道：

• 一個為指令通道(Command Channel)，預設使用 Port 21 建立連線，用來傳輸 FTP 指令，例如：列出檔案清單(LIST)、變更目錄(CWD)、取得目前的目錄(PWD)、......等。
• 另一個為資料通道(DATA Channel)，預設使用 Port 20，但是會因 FTP Client 選擇使用的「連線模式」不同而有所不同。

一般來說，指令通道的連線與下指令都沒有什麼問題，有問題的通常是在資料通道的建立，而資料通道的建立方式是由 FTP Client 所下的指令決定的，以 FileZilla 設定為例（如下圖）：

FTP Client (e.g. FileZilla) 每次建立連線時都會下 PORT 或 PASV 指令，如下範例：

指令:    PASV
回應:    227 Entering Passive Mode (59,37,124,43,158,251)

而每次下指令傳輸資料時，都會建立一次 data connection，包括取得遠端的檔案清單(LIST)時回傳的檔案列表、下載檔案、或上傳檔案。

連線模式

FTP 的連線模式分兩種：主動模式 ( Active mode ) 與 被動模式 ( Passive mode )

• 主動模式 ( Active mode )

FTP Client 跟 FTP Server 連線後，會主動利用 PORT 指令提出 DATA Channel 連線的要求，如下：

指令:    PORT 10,18,53,171,17,114
回應:    200 Port command successful.

這裡的 PORT 指令是由 FTP Client 送出的，當需要建立 DATA Channel 時，FTP Server 會主動利用 Server 主機的 Port 20 發出連線到 FTP Client 的主機，而 PORT 指令後的參數說明如下：

• 前四個數字是 FTP Client 的 IP 位址：10.18.53.171
• 後兩個數字是 FTP Client 接受連線的 Port 埠號，埠號的計算方式是 (第五個數字 * 256 + 第六個數字)，以此範例來說，FTP Client 接受的連線埠號是 17 * 256 + 114 = 4,466

由此可知，如果 FTP Client 處於 NAT 的環境下的話，FTP Server 幾乎無法正常的連線到 FTP Client 的主機，所以現在大部分的連線模式幾乎都建議使用者使用被動模式(Passive mode)。

• 被動模式 ( Passive mode )

FTP Client 跟 FTP Server 連線後，會主動利用 PASV 指令提出 DATA Channel 連線的要求，如下：

指令:    PASV
回應:    227 Entering Passive Mode (59,37,124,43,158,251)

你可以看到由 FTP Client 送出的 PASV 指令並沒有送出其他的參數，而是在 FTP Server 回應的時候出現了 (59,37,124,43,158,251) 字串，當需要建立 DATA Channel 時，這時就會由 FTP Client 主動連接至 FTP Server 動態開放的 Port 供 FTP Client 連接，其中 (59,37,124,43,158,251) 的說明如下：

• 前四個數字是 FTP Server 的 IP 位址：59.37.124.43
• 後兩個數字是 FTP Server 接受連線的 Port 埠號，埠號的計算方式是 (第五個數字 * 256 + 第六個數字)，以此範例來說，FTP Server 可接受的連線埠號是 158 * 256 + 251 = 40,699

由此可知，使用被動模式(Passive mode)對 FTP Server 的系統管理員來說，可掌控的部分是比較多的，因為 FTP Server 無法決定使用者是否可使用主動模式連線，但若改使用被動模式連線的話，就幾乎能讓所有人正常的使用 FTP 服務。

其他資訊

• 在 IIS 的 FTP 服務中，當使用 Passive mode 時，IIS FTP 會自動開啟短暫的 Port 用以建立 DATA Channel 供 FTP Client 連接，IIS 預設會動態使用 Port 1024 ~ 65535 進行 DATA Channel 的連線，若要修改預設的 Port Range 可以參考我昨天的文章：如何調整 IIS FTP 在 Passive mode 使用的 Port Range。
• 在 Linux kernel 中，若有設定 MASQ 的話，Kernel 已經支援「動態開啟 FTP DATA PORT」功能，也就是說在 FTP Client 端在 NAT 內部也能以 Active mode 使用 FTP，這就是為什麼有些人在公司內部使用虛擬 IP 也能夠使用主動模式(Active mode)傳輸檔案的情形。

相關連結

• Active FTP vs. Passive FTP, a Definitive Explanation
• 如何調整 IIS FTP 在 Passive mode 使用的 Port Range

FTP 有兩種傳輸模式，一種是主動模式(Active mode)，另一種是被動模式(Passive mode)，不過由於許多公司都是透過 IP 分享器上網，所以不是所有人都能透過 Active mode 傳輸檔案。而現在的 Server 環境也通常有架設防火牆阻擋沒在使用的 Ports，這種情況下也會讓 Passive mode 無法正常運作，因為當 FTP Server 在使用 Passive mode 傳輸資料時，Server 端會動態的使用 Port 1024 ~ 65535 來進行檔案的傳輸，這樣就很有可能被防火牆阻擋掉正常的連線。

所以我今天要教各位如何修改 IIS FTP 在 Passive mode 資料傳輸的 Port Range，這樣你就可以設定好 Firewall 讓這些 Port 開放給 FTP Server 使用。由於各版本的 IIS 設定的方式都不一樣，我假設要開放的 Port Range 從 5000 ~ 5100，以下是修改的方法：

IIS 5.0

• 開啟 regedit.exe
• 找到 HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Msftpsvc\ParametersPassivePortRange
• 修改內容為 5000-5100 即可。

IIS 6.0

• 開啟「命令提示字元」
• 進入 C:\Inetpub\AdminScripts 目錄
• 執行 adsutil.vbs set /MSFTPSVC/PassivePortRange "5000-5100"

我想很多習慣用線上版的 MSDN 查詢資料的人都知道每次要開啟一頁都要等好久，最主要是左側的目錄(TOC)資料很多，每次讀一個頁面大約要下載 1MB 左右的資料，又慢又浪費頻寬，微軟最近推出了個 LOBAND (低頻寬) 的版本，讓你在看線上 MSDN 文件時速度會快很多喔。

以 GridView Class 頁面為例， 其網址為 http://msdn.microsoft.com/en-us/library/system.web.ui.webcontrols.gridview.aspx，如果你要進入此頁的「精簡版」只要在 .aspx 前面加上 (loband) 就可以進入了，也就是 http://msdn.microsoft.com/en-us/library/system.web.ui.webcontrols.gridview(loband).aspx，不止英文版能用，中文版也是可以使用的，你只要將 en-us 改成 zh-tw 就可以了，所以我之前說的自動將 MSDN 英文文件翻譯成繁體中文版一樣也是可以用的。

所以原本的「完整版」（如下圖）

切換過去之後就會變成「精簡版」（如下圖）

如果你以後都要保持用「精簡版」查看文件的話，只要按下上圖右上方的 "Persist low bandwidth view" 之後就不用再手動加上 (loband) 到網址上了。

相關網址

• MSDN Low-Bandwidth Rendering Option

微軟最近推出了兩套 SQL Injection 偵測與防禦工具，分別是 Microsoft Source Code Analyzer for SQL Injection (MSCASI) 與 URLScan 3.0。

其中 Microsoft Source Code Analyzer for SQL Injection (MSCASI) 是專門用來分析早期 Active Server Pages (ASP) 程式中的 SQL Injection 漏洞，他會直接分析你的 ASP 原始碼並明確點出你的程式中潛在的 SQL Injection 漏洞在哪裡、潛在的風險、第幾行有問題等（如下圖）。如果你曾經寫過的 ASP 網站年久失修，建議你用這套工具執行看看是否有哪一段程式是有 SQL Injection 漏洞的。另外，微軟在前幾週也發表了一篇關於如何在 ASP 程式中防禦 SQL Injection 的建議（ Preventing SQL Injections in ASP），而這套工具就是依據這篇文章中所寫的幾個規則進行 ASP 原始碼分析的。

由於 Microsoft Source Code Analyzer for SQL Injection 是指令列程式，你下載後只要解壓縮就能用了，用法很簡單，你只要執行 msscasi_asp.exe 就會出現使用說明了。

G:\asp>msscasi_asp.exe
Microsoft (R) Source Code Analyzer for SQL Injection Version 1.3.30601.30622
Copyright (C) Microsoft Corporation.  All rights reserved.

Usage: msscasi_asp.exe [/nologo] [/quiet] [/suppress=num;..;num] [/GlobalAsaPath=
path] [/IncludePaths=path;..;path] /Input=file.asp

 ** msscasi_asp failure: no input file specified.

一次只能掃瞄一個檔案，底下是一個範例的用法：

msscasi_asp.exe /nologo /Input="c:\web1\test.asp"

你如果要掃瞄整個網站的 asp 程式你可以寫個批次檔來處理。

另一套軟體 URLScan 3.0 有別於已經推出五年之久的 UrlScan 2.5 版，功能多出了許多，他比較能夠主動偵測 SQL Injection 的攻擊，且目前也完整支援 IIS 7.0，不過未來這些掃瞄功能應該會直接整合進 IIS 7.0 中。

URLScan 3.0 版新增的功能有：

• Support for query string scanning, including an option to scan an unescaped version of the query string.
• Change notification for configuration (no more restarts for most settings.)
• UrlScan can be installed as a site filter.  Different sites can have their own copy, with their own configuration.
• Escape sequences can be used in the configuration file to express CRLF, a semicolon (normally a comment delimiter) or unprintable characters in rules.
• Custom rules can be created to scan the URL, query string, a particular header, all headers or combination of these.  The rules can be applied based on the type of file requested.
• Support for 64 bit IIS worker processes.

另外還有一套由 HP Web Security Research Group 發展出來的一個 SQL injection 偵測工具，叫做 Scrawlr 1.0，我覺得還挺酷的，用一個比較視覺化的方式偵測你的網站是否包含 SQL Injection 漏洞，只要輸入要檢測的網址，再按下 Start 按鈕就會開始跑了，非常的直覺、好用。如果你的網站被他抓到有漏洞的話，他還可以猜出你的資料庫名稱與相關資訊。

相關連結

• SQL Injection Defense Tools
• Microsoft ® Source Code Analyzer for SQL Injection – June 2008 CTP
• Giving SQL Injection the Respect it Deserves
• Preventing SQL Injections in ASP
• Filtering SQL injection from Classic ASP
• The HP Security Laboratory - Finding SQL Injection with Scrawlr
• How To: Protect From Injection Attacks in ASP.NET
• Coding techniques for protecting against Sql injection
• UrlScan v3.0 Beta Release
• How To：使用 URLScan ( URLScan 2.5 )
• 『資料隱碼』SQL Injection的源由與防範之道
• Stop SQL Injection Attacks Before They Stop You
• Microsoft Source Code Analyzer for SQL Injection 工具現已提供下載，可用來尋找 ASP 程式碼中的 SQL 隱碼攻擊弱點

Windows Sysinternals 是一套進階的系統管理工具，原本是由 Sysinternals Inc. 這家公司發產的產品（大多是免費的），可能因為做得太好了，在 2006 年 7 月時被微軟併購成為旗下的一套產品，這套產品中最有名的一個工具程式我覺得應該是 Process Explorer，他可以說是【Windows 工作管理員】的進階版，提供的資訊多到數不完，我想應該很多人都用過這個 Process Explorer 工具，但真的瞭解怎麼用的人我想應該不多吧，因為說明文件也沒寫什麼，我個人也沒有完全看的懂上面的所有欄位的真正意義（大概有上千個吧），我今天就說一些我經常在用的一些功能與查看有用資訊的技巧。

1. 程序之間的階層關係 & 判斷執行檔的類型

如上圖，我用紅色框線框起來的地方就是指我的 notepad++.exe 程式是從 WinKey.exe 執行起來的，但你可能會想，如果我將 WinKey.exe 砍掉，會不會也將 notepad++.exe 也連帶砍掉呢？其實是不會的，而是 notepad++.exe 會自動拉高到自己為主程序。

另外，你也可以很容易的使用顏色來區別執行檔的類型，其中：

• 黃色：代表此程式是一個 .NET 的應用程式。例如說我用 Process Explorer 就發現原來 Yahoo!奇摩輸入法 就有支程式是用 .NET 寫成的。
• 紫色：代表此程式是一個 Pack (包裝) 過的程式，也就是說這個程式本身又被包了一層程式，意思也就是說該程式是被「修改過」的程式，並非為原本的程式喔！通常這種程式有兩種可能：
  1. 中毒的程式：病毒讓你的程式還是可以正常運作，讓你覺得程式沒問題，但是私底下可能「多做了一些事」讓你沒感覺。
  2. 壓縮過程式：知名的 UPX (the Ultimate Packer for eXecutables) 工具程式就是專門用來將你製作出來的執行檔壓縮過，讓你的執行檔變小又能正常執行的工具。
• 粉紅色：此程式為一個 Windows 服務。

至於其他的顏色所代表的意義，你可以從功能選單的 Options -> Configure Highlighting 查得完整的顏色定義，當然你也可以修改掉，如下圖：

2. 查看該程序(Process)到底開啟了哪些檔案或使用到哪些 DLL

如上圖，你可以點選功能選單的 View -> Show Lower Pane 開啟 Lower Pane（或按下 Ctrl + L 快速鍵）查看程序載入了哪些 DLLs 或開啟了哪些 Handles (目錄, 檔案, 事件, 機碼, 執行緒, ..., etc. )

如上圖範例，我按下了 Ctrl + H 開啟 Handles View，你可以看到圖中的 KeyKeyServer.exe 開啟了一些檔案，以上圖為例我選取了 D:\Program Files\Yahoo!\KeyKey\zh-TW\Preference.resources.dll 程式，這時如果你想要刪除這個檔就會被通知「刪除檔案或資料夾發生錯誤」的錯誤訊息（如下圖），如果真的想強制刪除的話，可以在該 File Handle 上按下右鍵選擇 Close Handle 強制關閉這個 Handle，你就可以正常刪除檔案了，不過你原有的程式就很有可能會出錯或中斷執行，我是不太建議這麼做。

3. 查看完整的系統資訊

當你按下功能選單的 View -> System Information 或按下 Ctrl + I 快速鍵就可以看到這個完整的系統資訊，有時後我們電腦變慢可能跟 CPU 或 Memory 無關，而是 Disk I/O 過高導致拖慢程式執行的速度，透過這個畫面就可以一目了然你整台主機的運作狀況。

4. 瞭解你的 .NET 應用程式的執行狀態

有在寫 .NET 的人對這裡的技巧可能就會很有興趣了，我以 SharpReader 為例說明如何查看 .NET 相關的資料。我先啟動 SharpReader 應用程式，然後在 Process Explorer 上雙擊 SharpReader.exe 出現 Properties 視窗，然後點選 .NET 頁籤。

你會看見第一個區塊是 AppDomains，他會列出該程序所建立的所有 AppDomain 清單。下方是 .NET Performance Objects 區塊，這裡你就可以選擇不同的效能物件，用以查看該 .NET 應用程式的各種狀態。

.NET CLR Exceptions

• # of Exceps Thrown：這個程式總共發生了幾次 Exceptions，當你用 try / catch 捕捉到例外事件時，每捉到一次這邊就會加 1，你要知道 Exception 對效能的影響是很大的，對單機程式來說或許沒什麼差別，但是對多人使用的程式（如：ASP.NET）在人多的時候就會有差別了！
• Throw To Catch Depth / sec：代表他統計你的程式平均每秒捕捉到深度統計，因為 try / catch 是可以很多層的，我是不太知道算出這個數據有什麼意義，不過應該是數據越高越不好吧！

.NET CLR Interop

• # of CCWs：所謂的 CCW 是 COM Callable Wrapper 的縮寫，是指這個 .NET 程序中有幾個物件被封送(Marshaled)成 COM 物件。
• # of Stubs：代表這個 .NET 程序中有幾個成員(Members)被 Export 到 COM 物件供其他程式使用。
• # of marshalling：代表這個 .NET 程序中被封送(Marshaled)處理的總數。
• # of TLB imports / sec：所謂的 TLB 是指 Type Library 的縮寫，也就是平均有多少型別(Type)被匯入此 .NET 程序。
• # of TLB exports / sec：平均有多少型別(Type)被匯出到 COM 物件。

.NET CLR Jit

• # of Methods Jitted：代表到目前為止有多少方法(Methods)被編譯成機械碼(Machine Code 或 Native Code)。
• # of IL Bytes Jitted：有多少 MSIL 位元被轉譯成機械碼。
• Total # of IL Bytes Jitted：總共有多少 MSIL 位元被轉譯成機械碼。
• Standard Jit Failures：轉譯成機械碼失敗的次數。
• % Time in Jit：轉譯成機械碼所佔的時間百分比（因為可能有些程式寫了很多動態編譯的程式碼）。

.NET CLR Memory

這裡的物件就很重要了，雖然 .NET 有個很棒的自動記憶體管理機制，但並不代表你就可以完全不管，雖然再怎麼亂用也不會發生 memory leak 的問題，但卻很有可能會發生 OutOfMemoryException 例外狀況，或是因為資源回收器(GC, Garbage Collector)頻繁啟動而導致的程式執行效能降低的情況，因為每次資源回收器啟動時都會將程序中所有執行緒(Threads)凍結，以便讓 GC 檢查受管控的堆積(stack)。詳細的 GC 運作機制可參考 大內高手專欄 的 .NET 的自動記憶體管理 文章、.NET Framework記憶體回收機制 文章或 C# 精要 (C# Essentials) 一書，有意想深耕 .NET 領域的人不能不瞭解 GC 的運作機制，當你瞭解之後就看的懂底下這些欄位的定義代表什麼了。

其實還有許多其他相關的物件我沒有介紹，老實說我也不是全部都懂，但是等你越瞭解 .NET 的核心，就越能瞭解這些 Counter 所代表的意義。

其他相關連結：

• Profiling .NET Applications: Part 1
• Profiling .NET Applications: Part 2
• Profiling .NET Applications: Part 3

我只是想再特別提醒一下各位，如果你一定要動態載入控制項的話，一定要注意幾件事：

第一：熟悉 ASP.NET Page Lifecycle 很重要（事件執行的順序）

控制項的初始化(Initialize)的動作一定要放在 Page_Init 事件中！

控制項的初始化也包括設定控制項的預設值(Default Value)。

千萬不能將設定控制項初始值的程式碼寫在 Page_Load 事件裡，否則當 PostBack 回來的值會被 Page_Load 事件中的程式碼蓋掉。

動態將控制項加入到 ASP.NET 頁面中「最好」在 Page_Load 事件中執行，以確保在後續事件中可以取得頁面中所有的控制項。

第二：要特別留心控制項加入的順序

動態將控制項加入到 ASP.NET 頁面中時，要特別注意「控制項加入的順序」，順序很重要，只要加入的順序不對就很有可能會在 PostBack 的時候發生 ViewState 異常的狀況，各位可以參考我之前寫的一篇文章：釐清 ViewState 與動態加入的控制項可能發生的錯誤

第三：ViewSate 是個低調的怪獸，能不用就不用

你知道光是談 ViewState 就可以出一本書嗎！

老實說，ViewState 真的很好用，用的人也很多，誤用的人也很多，敗在 ViewState 上面的人也很多。所以一件事情所帶來的好處，背後通常也潛藏著某些不為人知的壞處。我剛學寫 ASP.NET 的時候，曾經寫過一個線上預約系統，因為頁面超複雜，一大堆控制項都是動態加入的，每次 PostBack 大概都要送出 1MB 左右的 ViewState 資料，當初剛學 ASP.NET 也不知道為什麼會這樣，只是覺得為什麼 ASP.NET 執行速度這麼慢，等要結案的時候才發現原來是 ViewState 搞的鬼，光是改另一種寫法就寫死我了。

所以我對 ViewState 一直沒什麼好感，後來我的態度是「我一定要徹底瞭解 ViewState，並且在未來的日子裡能不用就不用它」。既然不用又為何要瞭解的？因為如果你不深入瞭解一項技術背後設計的動機與嘗試解決的問題，你就無法從這項技術得到啟發，並發展出另一套更適合自己的開發架構。

短短的三點提醒，一定不足以應用所有的開發情境，所以各位若能貢獻一些動態載入控制項開發時的注意事項，十分歡迎在此留下些評論，互相交流交流。

身為一個程式設計師最討厭的就是被侷限在框框裡寫程式，我們唯一的限制應該是在我們的創意而非架構。像 LINQ 剛出來的時候我覺得超級好用，不過等用在專案上實做的時候才發現綁手綁腳的，想要動態組成一個 LINQ 語法難上加難，結果過沒多久就在 ScottGu's Blog 看到一篇 Dynamic LINQ (Part 1: Using the LINQ Dynamic Query Library)，看到的時候好像挖到寶一樣，以前在開發時卡住的問題全部都解決了，從今年 2 月份用到現在簡直是幾乎忘了它的存在，以致於這幾個月都沒有提及 Dynamic LINQ 這個好東西，直接上週一個朋友問我：『LINQ 的 Where 條件可以像以前組 SQL Command 一樣動態組裝嗎？』，我馬上跟他說有 Dynamic LINQ 這個東西，不用多說，他跟我剛看到 Dynamic LINQ 的時候一樣覺得：Bravo! ( 太棒了 )

這個 Dynamic LINQ 其實也跟我曾經介紹過的 好用的 Linq Samples and the Sample Query Explorer 一樣，早就出現在 VS2008 的 CSharpSample 裡面了，有需要的人可以到這裡下載，下載回來後這個 Library 放在 \LinqSamples\DynamicQuery\ 專案裡，專案裡面有個 Dynamic.cs 是一堆 Extension Methods，用來擴充 LINQ 的現有功能，程式碼有點複雜，想專精 LINQ 的人可以好好研究一下這些原始碼，共有 2,027 行。如果沒空看也沒關係，會用就很夠了，你可以看專案內的 Program.cs 提供一些簡單的範例，不用多說，看個範例你就知道他在做什麼了：

Northwind db = new Northwind(connString); 
db.Log = Console.Out;

var query =
    db.Customers.Where("City == @0 and Orders.Count >= @1", "London", 10).
    OrderBy("CompanyName").
    Select("New(CompanyName as Name, Phone)");

Console.WriteLine(query);
Console.ReadLine();

我介紹到這裡就好，大家如果有感覺的話，可以到 Dynamic LINQ (Part 1: Using the LINQ Dynamic Query Library) 或 动态LINQ （第一部分：使用LINQ动态查询库） 查看更完整的範例，或者可以用搜尋引擎查詢 Dynamic LINQ 也可以找到一堆資料。

不過，使用 Dynamic LINQ 有個缺點，就是這種寫法就會失去編譯時期偵錯(Compile-time Debugging)的機會，如果你自己組成的 LINQ 語法有問題的話，就必須要到執行時期(Runtime)才有可能找到錯誤了，這時你就必須要做好錯誤處理(Error Handling)才行！

我最近找到了一個 Outlook 的設定，可以不用將所有寄出的郵件放在「寄件備份」資料夾內，而是當回覆信件的時候，所寄出的郵件會自動儲存在原本信件所在的資料夾內。

我以往都沒有特別思考過為什麼寄出的郵件都要放在寄件備份裡，因為有時候還挺不方便的，有時後我在回顧過去郵件查資料的時候，會想找出該郵件曾經回覆給誰、何時回覆的，雖然我們可以點開郵件後點選郵件上方的資訊列，點擊「尋找相關訊息」搜尋，不過像我的「寄件備份」裡就有 3 千多封信，用 Outlook 內建的郵件搜尋功能來尋找相關訊息速度非常的慢。

所以我調整了一下我 Outlook 的選項設定，如下圖點選「電子郵件選項」進去：

然後再點選「進階電子郵件選項」進去：

最後就勾選「回覆時在資料夾保留原郵件內容」即可：

不過這個選項在 Outlook 英文版的翻譯是 "In folders other than the Inbox, save replies with original message"，也就是說如果你在「收件夾」回信的話，郵件還是會儲存到「寄件備份」去的，這點要特別注意，因為你可能會在「收件夾」測試這個功能試到抓狂！

而之後你可以設定不同的「檢視/排列」方式，將他切換到「交談主旨」模式，Outlook 就會自動將你的郵件依據交談主旨群組在一起了：

切換「交談主旨」過去後的郵件排列方式就會變成如下圖的樣子：

我感覺這樣的排列比較有意義一點，下次就不用到處尋找郵件了。

基本上，網頁遇到「中文字」超過一行時都可以正常的斷字，只是若是英文字寫了一大串沒有空白的字，就會導致網頁版型被撐開，如下圖例就是因為網址過長而導致網頁被撐版，進而影響頁面的呈現。

IE 從 5.5 ~ 8.0 版的 CSS 都有支援一個 word-wrap 屬性，當你指定屬性值為 break-word 時就可以強迫瀏覽器進行斷字的動作，這樣就可以避免文字被斷行了。

不過要在 Firefox 中使用 word-wrap 就不可行了，一直到前天才正式發佈的 Firefox 3.0 也還是不支援 word-wrap 屬性，不過 word-wrap 屬性已經被編進 CSS 3.0 的規格中了，相信遲早有一天可以支援的。

不過在 Firefox 中也不是完全沒辦法，網路上有篇文章就有寫到如何在 Firefox 中實現自動斷字的方式，有興趣的可以上去看看。

我這裡摘要一下要達到目的必須的步驟：

1. 在 CSS 中定義一個 wordwrap 類別

.wordwrap
{
    word-wrap: break-word;
    -moz-binding: url('wordwrap.xml#wordwrap'); 

    display: block;
    overflow: auto;
}

這幾行 CSS 定義都是有意義的，內容這四行我大致解釋一下：

第一行：給 IE 看的，讓斷字產生。

第二行：給 Firefox/Mozilla 看的，透過 binding 的方式執行一段 JavaScript，當 Element 套用此 wordwrap 類別時讀取 wordwrap.xml 檔案，裡面有定義一組JavaScript程式可動態執行。

第三行、第四行：wordwrap.xml 裡面定義當 overflow 事件發生時執行一段程式讓文字斷行，所以 display 屬性一定要設定成 block 才有可能引發 overflow 事件（使用 inline 是沒辦法的），而最後的 overflow 就設定成 auto 即可。

2. 新增一個 wordwrap.xml 檔案

<?xml version = "1.0"?>
<bindings xmlns = "http://www.mozilla.org/xbl" xmlns:html = "http://www.w3.org/1999/xhtml">
  <binding id="wordwrap" applyauthorstyles="false">
    <implementation>
      <constructor>
        //<![CDATA[
            
            var elem = this;

            elem.addEventListener('overflow',
                function()
                {
                    var exp = /<&#8203;\/*[&#8203;_\s="'\w]+>/g;
                    
                    var txt = elem.innerHTML;
                    var chars = txt.split('');
                    var newTxt = chars.join('&#8203;');                    
                    newTxt = newTxt.replace(exp, reconstructTag);                    
                    elem.innerHTML = newTxt;
                },false);
                
                function reconstructTag(_tag)
                {
                    return _tag.replace(/&#8203;/g, '');
                }

            //]]>
      </constructor>
    </implementation>
  </binding>
</bindings>

內容我就不詳述，請自行到 Emulating CSS word-wrap for Mozilla/Firefox 閱讀相關說明。

3. 最後，到你的 HTML 中會破版的那個標籤套上 wordwap 類別即可。

<span class="url wordwrap">一個非常長的網址.....</span>

在我的例子裡，套用之後在 Firefox 中的顯示效果如下：

就這樣三個步驟就可以達成完美、跨瀏覽器的自動斷字功能。這裡有個線上的 DEMO，你們可以用 Firefox 去看看執行的效果如何。

相關連結

• MSDN Library - word-wrap Attribute | wordWrap Property
• Cascading Style Sheets (CSS), Level 3 (CSS3)
• Emulating CSS word-wrap for Mozilla/Firefox