IM的服務器壓力測試今天完成了。總的來說，測試結果令人滿意。

IM服務器配置如下：
CPU：至強3G雙核 x 1
內存：1G
硬盤：140G SISC硬盤
IM服務之外的其余服務：
IM & 客戶端 自動更新服務
公司網站web服務
公司郵件服務

測試方式：
3臺計算機并發模擬客戶登陸及聊天。登陸包括查詢與下載好友列表、好友資料、群組列表、群組資料；聊天測試方式為，每個模擬客戶端每1秒向好友列表中的一個好友發送一條文本消息。所有好友消息均為服務器轉發，因為如果使用P2P方式的話，一旦P2P通道建立，數據便不再經過服務器，對IM服務器的壓力不產生影響，因此，便沒有測試P2P方式下的壓力數據，而選擇測試服務器轉發方式下的壓力數據。

最終的測試結果為：
服務器轉發模式下，大約能同時支持3000人登陸，4865人同時聊天（服務器崩潰前最近一次讀數）。
光登陸就超過2000，令人非常滿意，而且4865人同時聊天，這還是在未進一步優化的情況下獲得的數據。接近5000的數據，令人很是高興。

最后，IM服務器的架構簡述：
采用4IOCP。其中一個TCP IOCP用作管理員客戶端連接，以及將來的服務器聚合擴展；一個TCP IOCP用于用戶客戶端登陸登出，以及數據補包；一個UDP IOCP用于心跳、P2P打洞處理、中轉聊天的文字消息（包含系統表情）；一個UDP IOCP用于中轉聊天的非文本數據（比如圖像）。4個IOCP間的橋接及系統日志、管理員日志、用戶日志、插件日志均采用隊列處理。系統所有內存使用均有專門的內存管理器負責管理。至于UDP為什么也要采用IOCP，原因則是，雖然普通的UDP已經很快了，但是，每次發送，接收仍均需要阻塞等待。雖然每次阻塞的時間很短，但積少成多，在大量連接的情況下，仍然會比較可觀。而采用IOCP，則就是為了經量減小每次阻塞的時間。
最后，關于系統資源占用：
CPU：4%-9%。即使達到4865用戶同時在線聊天，CUP占用率也一直處于4%-9%
內存：IM服務器剛剛啟動時，占用內存7M多，當4865用戶同時采用服務器中轉方式在線聊天時，達到190M。

生命是一場輪回，有些事注定要發生。有些人注定要離去……

 
　 先關閉所有的IE瀏覽器窗口鼠標右鍵點擊快速啟動欄的IE瀏覽器圖標，在出現的快捷菜單中點擊“屬性”，系統隨即彈出“啟動Internet Explorer瀏覽器屬性”對話頁面，點擊“快捷方式”標簽，在出現的頁面的“運行方式(R)”中單擊右側的下拉條，選擇“最大化”。之后按“確定”退出。打開IE瀏覽器窗口，點擊里面的鏈接，接著關閉先前打開的IE瀏覽器窗口,只留下這個鏈接頁面，拉動邊框將其窗口拉到整個屏幕，然后關閉該頁面。從此，您打開IE瀏覽器窗口直接就是最大化的頁面了。如果這方法不靈，那可得改修改您的計算機的注冊表了，方法：打開“注冊表編輯器”，找到[HKEY_ CURRENT_USER＼Software＼Microsoft＼Internet Explorer＼Desktop＼Old WorkAreas]，然后選中窗口右側的“OldWorkAreaRects”，將其刪除；在“注冊表編輯器”中找到[HKEY_CURRENT_USER＼Software＼Microsoft＼Internet Explorer＼Main]，選擇窗口右側的“Window_Placement”，將其刪除；退出“注冊表編輯器”，重啟電腦，然后打開IE，將其窗口最大化，并單擊“向下還原”按鈕將窗口還原，接著再次單擊“最大化”按鈕，最后關閉IE窗口。以后重新打開IE時，窗口就正常了！

        如今，軟件開發越來越復雜，軟件功能也越來越豐富。而幾乎所有成熟的商業軟件，都是靠一個開發團隊齊心協力的血汗結晶。“羅馬不是一天建成的！”，當我們震撼于Microsoft Windows的驚世巨著的同時，也道聽途說了微軟公司軟件工程是如何的完善規范。的確，集數百名員工幾年的共同努力之大成，軟件項目管理的成敗是控制開發成本的關鍵環節。這里面，少不了貫穿其中的重要步驟----軟件文檔。軟件文檔可以分為開發文檔和產品文檔兩大類。開發文檔包括：《功能要求》、《投標方案》、《需求分析》、《技術分析》、《系統分析》、《數據庫文檔》、《功能函數文檔》、《界面文檔》、《編譯手冊》、《QA文檔》、《項目總結》等。產品文檔包括：《產品簡介》、《產品演示》、《疑問解答》、《功能介紹》、《技術白皮書》、《評測報告》、《安裝手冊》、《使用手冊》、《維護手冊》、《用戶報告》、《銷售培訓》等。
 一、開發文檔
1. 《功能要求》--來源于客戶要求和市場調查，是軟件開發中最早期的一個環節。客戶提出一個模糊的功能概念，或者要求解決一個實際問題 ，或者照同類軟件的一個功能。有軟件經驗的客戶還會提供比較詳細的技術規范書，把他們的要求全部列表書寫在文檔中，必要時加以圖表解說。這份文檔是需求分析的基礎。
2. 《投標方案》--根據用戶的功能要求，經過與招標方溝通和確認，技術人員開始書寫《投標方案》，方案書一般包括以下幾個重要的章節：前言--項目背景、公司背景和業務、技術人員結構、公司的成功案例介紹等。需求分析--項目要求、軟件結構、功能列表、功能描述、注意事項等。技術方案--總體要求和指導思想、技術解決方案、軟件開發平臺、網絡結構體系等。項目管理--描述公司的軟件開發流程、工程實施服務、組織和人員分工、開發進度控制、軟件質量保證、項目驗收和人員培訓、軟件資料文檔等。技術支持--公司的技術支持和服務介紹、服務宗旨和目標、服務級別和響應時間、技術服務區域、技術服務期限、授權用戶聯系人等。系統報價--軟、硬件平臺報價列表、軟件開發費用、系統維護費用等。項目進度--整個項目的進度計劃，包括簽署合同、項目啟動、需求分析、系統分析、程序開發、測試維護、系統集成、用戶驗收、用戶培訓等步驟的時間規劃。
3. 《需求分析》--包括產品概述、主要概念、操作流程、功能列表和解說、注意事項、系統環境等。以《功能要求》為基礎，進行詳細的功能分析(包括客戶提出的要求和根據開發經驗建議的功能)，列出本產品是什么，有什么特殊的概念，包括那些功能分類，需要具備什么功能，該功能的操作如何，實現的時候該注意什么細節，客戶有什么要求，系統運行環境的要求等。這里的功能描述跟以后的使用手冊是一致的。
4. 《技術分析》--包括技術選型、技術比較、開發人員、關鍵技術問題的解決、技術風險、技術升級方向、技術方案評價，競爭對手技術分析等。以《需求分析》為基礎，進行詳細的技術分析(產品的性能和實現方法)，列出本項目需要使用什么技術方案，為什么，有哪些技術問題要解決，估計開發期間會碰到什么困難，技術方案以后如何升級，對本項目的技術有什么評價等。
 5. 《系統分析》--包括功能實現、模塊組成、功能流程圖、函數接口、數據字典、軟件開發需要考慮的各種問題等。以《需求分析》為基礎，進行詳細的系統分析(產品的開發和實現方法)，估計開發期間需要把什么問題說明白，程序員根據《系統分析》，開始在項目主管的帶領下進行編碼。
6. 《數據庫文檔》--包括數據庫名稱、表名、字段名、字段類型、字段說明、備注、字段數值計算公式等。以《系統分析》為基礎，進行詳細的數據庫設計。必要時可以用圖表解說，特別是關系數據庫。
7. 《功能函數文檔》--包括變量名、變量初植、功能，函數名，參數，如何調用、備注、注意事項等。以《系統分析》為基礎，進行詳細的說明，列出哪個功能涉及多少個函數，以便以后程序員修改、接手和擴展。
8. 《界面文檔》--包括軟件外觀、界面素材、編輯工具、文件名、菜單、按鈕和其它界面部件的要求，這里與軟件完成后的運行界面是一致的。
9. 《編譯手冊》--包括服務器編譯環境、操作系統、編譯工具、GNU的C++編譯器版本信息、目錄說明、程序生成、源程序文件列表、Makefile配置及其相關程序的對應關系列表。客戶端的編譯過程、編譯結果、編譯示例、編譯環境、操作系統、編譯工具、源文件列表和制作安裝程序的過程。
10. 《QA文檔》--包括產品簡介、產品原理、產品功能列表、功能描述、功能流程、執行結果、數據庫結構、測試要求等，提供給軟件測試人員使用。
11. 《項目總結》--包括項目簡介、項目參與人員和開發時間

 

CMMI標準名詞術語

1 AT Assessment Team 評審小組
2 ATM Assessment Team Member 評審小組成員
3 BA Baseline Assessment 基線評審
4 CAR Causal Analysis and Resolution 原因分析與決策
5 CBA CMM-Based Appraisal 基于CMM的評價
6 CBA-IPI
CMM-Based Appraisal for Internal Process
Improvement
為內部過程改進而進行的基于CMM的評價（通常
稱為CMM評審）
7 CC Configuration Controller 配置管理員
8 CF Common Feature 公共特性
9 CFPS Certified Function Point Specialist 注冊功能點專家
10 CI Configuration Item 配置項
11 CM Configuration Management 配置管理
12 CMM Capability Maturity Model 能力成熟度模型
13 CMMI Capability Maturity Model Integration 能力成熟度集成模型
14 COTS Commerce off the shelf 商業現貨供應
15 DAR Decision Analysis and Resolution 決策分析與制定
16 DBD Database Design 數據庫設計
17 DD Detailed Design 詳細設計
18 DP Data Provider 數據提供者
19 DR Derived Requirement 派生需求
20 EPG Engineering Process Group 工程過程小組
21 FP Function Point 功能點
22 FPA Function Point Analysis 功能點分析
23 FR Functional Requirement 功能性需求
24 GA Gap Analysis 差距分析
25 ID Interface Design 接口設計
26 IFPUG International Function Point Users Group 國際功能點用戶組織
27 IPM Integrated Project Management 集成項目管理
28 IR Interface Requirement 接口需求
29 KPA Key Process Area 關鍵過程域
30 KR Key Requirements 關鍵需求
31 LA Lead Assessor 主任評審員
32 MA Measurement and Analysis 測量與分析
33 MAT Metrics Advisory Team 度量咨詢組
34 MCA Metrics Coordinator and Analyst 度量專員
35 ML matreraty library 度量數據庫
36 NFR Non-functional Requirement 非功能性需求
37 OC Operational Concept 操作概念
38 OID Organizational Innovation and Deployment 組織革新與部署
39 OPD Organizational Process definition 組織過程定義
40 OPF Organizational Process focus 組織過程焦點
41 OPL Organizational Process Assets 組織過程財富
42 OPP Organaizational Process Perormance 組織過程性能
43 OSSP Organization’s Set of Standard Process
組織標準過程集合
44 OT Organizational Training 組織級培訓
45 PA Process Areas 過程域
46 PAT Process Action Team 過程行動小組
47 PB Process Assets Library 過程財富庫
48 PD Preliminary Design 概要設計
49 PDSP Project Defined Standard Processes 項目定義標準過程
50 PI Produce Integration 產品集成
51 PLC Product Life Cycle 產品生命周期
52 PMC Project Monitoring and Control 項目監控
53 PP Project Planning 項目策劃
54 PPQA Process and Product Quality Assurance 過程與產品質量保證
55 PPR Price Performance Ratio 性能價格比
56 QA Software Quality Assurance 軟件質量保證
57 QA Quality Assurance 質量保證
58 QAP Software Quality Assurance Plan 質量保證計劃
59 QPM Quantitative Project Management 量化項目管理
60 RD Requirements Development 需求開發
61 RM/ReqM Requirements Management 需求管理
62 RSKM Risk Management 風險管理
63 RTM Requirement Traceability Matrix 需求跟蹤矩陣
64 SAM Supplier Agreement Management. 供應協議管理
65 SC Steering Committee 指導委員會
66 SCAMPI
Standard CMMI Assessment Method for
Process Improvement 過程改進CMMI標準評審方法
67 SCCB Software Configuration Control Board 軟件配置管理控制委員會
68 SCM Software Configuration Management 軟件配置管理
69 SDP Software Development Plan 軟件開發計劃
70 SEI Software Engineering Institute (美國)軟件工程學院
71 SEPG Software Engineering Process Group 軟件工程過程組
72 SPI Software Process Improvement 軟件過程改進
73 SPP Software Project Planning 軟件項目策劃
74 SPTO Software Project Tracking and Oversight 軟件項目跟蹤與監控
75 SR System Requirements 系統需求
76 SRS Software Requirement Specification 軟件需求規格
77 SSM Software Subcontract Management 軟件分包管理
78 SSR Software System Requirement 軟件系統需求
79 TS Technical Solution 技術解決方案
80 UC Use Case 用例
81 UID User Interface Design 用戶界面設計
82 VAL Validation 確認
83 VER Verification 驗證
84 WBS Work Breakdown Structure 工作分解結構
85 WP Work Products 工作產品
86 Pre-assessment 預評審
87 Baseline 基線
88 Quality Attribute 質量屬性
89 Scenario 場景

 

鞠強

 

 

         這是一篇關于成長的心得。仁者見仁、智者見智，如果諸位讀者能夠從此文中看出一點東西來，有所感悟，我就滿足了。

         我是數學系畢業的，大二開始搗鼓計算機（94年），最大的興趣就是寫程序。改游戲、改病毒，這些小東西讓人很有成就感。工作后的興趣經歷了一個很大的轉變（當然，這個時間相對于多數人而言，遲了些），2000年的時候，我突然發現了我寫的程序的價值。當我看到我修改了短短的幾行代碼的時候，給客戶帶來了很大的效率提升，降低了成本，那種成就感，遠非6年前的認識可比了。

         本文并非專門面對計算機入門者，所以內容比較雜。

         此段權作前言，現在進入正題。

知識點要連貫，知識面要廣

         國內的大部分軟件企業，從來沒有像國外那樣，在技術上保持連續性。從微軟這條路線來看，從最早的DOS->Win16->Win32->OLE->DCOM，到COM+->.NET，我們很難找到能夠完整走完這個歷程的人。這種現狀，導致大部分的技術人員，對于開發技能，有一個很大的斷層：知其然，不知其所以然；碰到非source code的錯誤，就手足無措；或者代碼質量低劣，或者性能有很大瓶頸。

         上面的路線演進，可以認為是“工程”方面的，而非我們大學教育中的“科學”。操作系統、數據庫、數據結構、離散數學，這些內容非常重要。但是我們要注意的是，你學習了這些，不代表就能寫好一個程序，能夠解決客戶的問題。工程方面的東西，我們多加掌握，熟練應用，配合上述“科學”的內容，才能真正保證程序價值的發揮。

而如何讓兩者有機的結合起來？我想，不外乎就是興趣+經驗。

         在微軟平臺上開發，很重要的一個資源就是MSDN（Microsoft Software Development Network），里面有how to，有concepts，有topics，可以讓我們更好更快的上手。當我們碰到某個代碼錯誤，想找某種解決方案的時候，MSDN是一個非常好的助手。對于初學者，我們可以看里面的how to，step by step的進行學習。

         還有一個笨辦法，我剛工作時候采用的，就是找一個老版本的SDK說明文檔（borland開發工具的幫助里面就有，那個短小精悍，沒有msdn的那么復雜），從字母A開始，到字母Z，我當時花了一年半的時間，基本把所有的API都試驗了一遍。這么做有個好處，能讓你快速的對整個開發有一個概覽。以后在學習或者工作中碰到了問題，能讓你有一個大概的印象，知道應該怎么做，知道應該用哪個API

        對于現在的應用而言，如果是基于.NET的企業級應用開發，我的經驗是，Win32 API了解即可（當然，如果對某一方面很熟練的話，還是非常有好處的。如socket、GDI等。）；COM/COM+要知道一些，至少要清楚Add/Release Reference的含義；.NET Framework要深入一些。比如可以拿那本《.NET 高級編程》來做練習。這本書1000多頁，雖然名之為“高級”，但你可以拿它當字典來用。有興趣的，可以按照我說的那個笨辦法，從第一章開始到最后一章，讀一遍之后，自己一個字母一個字母的，把所有的代碼寫上、調試通過、運行，并反復debug，從中了解語法、語義、一些編程技巧。

       對于高質量的代碼而言，仔細研讀《Essential .NET》這本書是很有必要的。

        對于企業級應用開發，還有一點很重要，就是數據庫知識。數據庫本身的語法很簡單，關鍵是我們寫出來的sql要成本低，成本低一般就會帶來效率的提升（并非絕對如此）。這部分內容，一需要經驗，二需要思想意識的轉變。什么思想意識呢？就是要有數字化的觀點！

         舉個例子，客戶讓你出一份能夠適應未來三年需求的存儲方案，你該如何考慮？如果沒有數字的觀點，很可能的結果就是瞎蒙出來的數字。如果有了數字觀點，我們很容易提供此方案。

        對于存儲空間,我們可以仔細分析客戶最近2-3年的數據庫結構、內容，加以咨詢客戶，未來3年的應用變化趨勢，最終我們能得到這樣一份提綱：

	帳務管理	發票管理	訂單管理
用戶個數	50	20	100
高峰時間段	月底3天	每日	每日
每行記錄大小（kb）	20	10	200
業務發生筆數（每天）	30	50	50
高峰期業務發生筆數（每天）	100	50	50

 

假設每個月工作日是22天，那么計算每個月的高峰期業務量、平時業務量，得到一個總數，乘以36個月，就能得到一個統計意義上的3年業務量。再考慮到tempdb、日志、索引，以及raid，我們就能很容易的得到存儲空間數字。再通過TPC等要求，得到服務器的其他配置要求。

 

         當你寫的代碼被別人應用的時候，總會有這樣、那樣的問題。硬件，可能會和程序不兼容；軟件，新操作系統你可能不支持；木馬可能讓你的B/S代碼發生莫名其妙的故障；病毒會導致你的.NET runtime頻繁重啟；BT/emule讓你的應用沒有帶寬用、socket無法連接，等等……

         諸如此類的問題，絕對不是我們在電腦旁邊寫程序時，就能想到的。那怎么辦呢？我們雖然做不到全才，但是要利用好你所處的團隊，利用好網絡資源。這兩點做到了，當你積累了相當的經驗，再考慮新的程序的時候，就能有所警覺，讓新程序的架構更為合理。（對于架構，牢牢記住這些：伸縮性、擴展性、可靠性，以及安全、性能。）

當你對架構有所了解的時候，你又會發現，細節決定了一切。細節的處理，來自于你的知識面、項目經驗，以及大量的思考。無論.NET還是J2EE，無論是C#還是C++，平時多了解一些，總會對你思考整個軟件，帶來益處的。

 

軟件開發是一項事業

         軟件是一個非常累的行業，如果想拿高薪、每天八小時工作、周六周日有自己的私人空間，那么在這個行業你幾乎找不到合適的切入點。

對于許多新人而言，這個行業充滿了誘惑，也有很多挑戰。興趣，也許是選擇這個行業的第一前提。當我發現我寫的程序能夠控制企業的生產設備時，無疑是很興奮的；當我發現我的代碼總是會莫名其妙的crash，無疑又是很沮喪的。很快，我們的興趣就容易被這些抽風似的問題，磨滅殆盡。

也許可以這么說，興趣是領我們進門的老師，你能讓它跟你越久，你就越能保持前進的動力。如果沒有了，這也是一個好事。我在工作后的第三年，突然對所做的一切失去了興趣。后來想，這說明我已經度過了那個純粹感性認識的階段，“可以”朝理性階段邁進了。

就這個行業本身而言，我們更多的接觸客戶、更多的接觸實際需求，這些帶來的沖擊，遠比一種新技術對我們的影響，要猛烈的多。客戶那里有各式各樣的硬件環境、網絡環境、軟件環境，有各種管理模式的應用。接觸的久了，我們自然就會思考：

l 我寫的代碼，該如何改進，才能適應各種環境？

l 應用上采用什么架構，可以滿足可預見到的未來的需求？

l 怎么做，能讓程序在sqlserver和oracle、db2上都跑的很好？

l 安全上，代碼中的sql injection，真是那么容易解決的嗎？

l 我的程序能夠無縫的在客戶那里的.NET Frame1.1/2.0上切換嗎？

l 我的程序，如何能在windows 2000上跑的更快？

 

當我們有了這些思考，實際上，興趣就又回來了。這些問題毫無疑問，都不簡單，但都很有意思。我相信，這是一個良性的循環。興趣、事業，交替引導著我們前行。

 

不要急于為自己定位

         工作了2、3年之后，我們都會有這個困惑：我以后做什么？繼續作程序員？作管理？想的再遠一些，30歲之后，我們應該做什么？

         這個問題，我曾經問過我的老板，他和我說，你把自己當前的工作做好，好的要做的更好。今后的發展，是和你目前所做的工作、你的視野、你的經驗，息息相關的。

         功到自然成。

        

如何看待IT這個行業

         我認為IT行業，現在剛剛是起步階段，這個階段也許持續20年或者更長。IT的最終目標，應該是作為一種基礎服務，沉淀在經濟發展大潮下面。如同水、電、煤氣一樣，我們日常感受不到它們的存在。一旦停電、停水、停氣，我們才會感覺到不便，才會發現，整個經濟的運轉，都離不開這些基礎設施。

         軟件方面，最終也會發展到這么一個階段。黑客帝國二里面，議會老大和NEO在談論matrix和“真實”世界，透過繁榮，背后是巨大的能量供應基地、星羅棋布的管道，這一切看起來丑陋的東西，被深深地印藏在背后了。

 

         從目前來看，軟件還是在盡量的模擬世界，盡量的從數據中發現我們所生存的這個世界的真相。這首先需要我們把所有能發現的現象，都抽象出來，需要龐雜的數學理論支持，需要硬件的革命性地變化支撐。

但這是一個非常困難的工作，也許幾代人的時間我們才能做到。我們目前所做的，正是這偉大變革的第一步。

做好選擇：進大公司？進小公司？

         每個臨近畢業的，致力于搞軟件的人都會有這個抉擇：進大公司？進小公司？

         大公司門檻高，組織結構復雜，層級很多，待遇也許不會太好，高手眾多。Freshman也許要適應幾年的時間，才能展露頭角。

         小公司門檻低，結構單一，待遇相對會好。新手很容易抓住機會，在項目中成長起來。

 

         眾多走過來的人都有這個經驗，大公司里面你會學到很多東西，各方面會正規一些；小公司的生存壓力比較大，也許你會成為一個多面手，但成為一個高手，會很困難。道理很簡單，一個是發展階段，一個是生存期，這兩種狀態決定了公司的運營狀態，決定了軟件研發的思路，決定了市場思路。

 

         我個人的體會是，開始進入大公司，應該是一個不錯的抉擇。如果進了小公司，就要考慮如何踏實的把工作做好先，如何能夠全面、快速的成長。

 

 

 

作者鞠強，10年的企業管理軟件開發經驗，目前致力于產品性能、安全方面的研究。我的聯系方式是：濟南市山大路224號，浪潮通軟，郵編250103。聯系電話：138 5310 1310，MSN是：juqiang1975@msn.com

功能測試就是對產品的各功能進行驗證，根據功能測試用例，逐項測試，檢查產品是否達到用戶要求的功能。常用的測試方法如下
　　1. 頁面鏈接檢查：每一個鏈接是否都有對應的頁面，并且頁面之間切換正確。

　　2. 相關性檢查：刪除/增加一項會不會對其他項產生影響，如果產生影響，這些影響是否都正確。

　　3. 檢查按鈕的功能是否正確：如update, cancel, delete, save等功能是否正確。

　　4. 字符串長度檢查: 輸入超出需求所說明的字符串長度的內容, 看系統是否檢查字符串長度,會不會出錯.

　　5. 字符類型檢查: 在應該輸入指定類型的內容的地方輸入其他類型的內容(如在應該輸入整型的地方輸入其他字符類型),看系統是否檢查字符類型,會否報錯.

　　6. 標點符號檢查: 輸入內容包括各種標點符號,特別是空格,各種引號,回車鍵.看系統處理是否正確.

　　7. 中文字符處理: 在可以輸入中文的系統輸入中文,看會否出現亂碼或出錯.

　　8. 檢查帶出信息的完整性: 在查看信息和update信息時,查看所填寫的信息是不是全部帶出.,帶出信息和添加的是否一致

　　9. 信息重復: 在一些需要命名,且名字應該唯一的信息輸入重復的名字或ID,看系統有沒有處理,會否報錯,重名包括是否區分大小寫,以及在輸入內容的前后輸入空格,系統是否作出正確處理.

　　10. 檢查刪除功能:在一些可以一次刪除多個信息的地方,不選擇任何信息,按”delete”,看系統如何處理,會否出錯;然后選擇一個和多個信息,進行刪除,看是否正確處理.

　　11. 檢查添加和修改是否一致: 檢查添加和修改信息的要求是否一致,例如添加要求必填的項,修改也應該必填;添加規定為整型的項,修改也必須為整型.

　　12. 檢查修改重名:修改時把不能重名的項改為已存在的內容,看會否處理,報錯.同時,也要注意,會不會報和自己重名的錯.

　　13. 重復提交表單：一條已經成功提交的紀錄，back后再提交，看看系統是否做了處理。

　　14. 檢查多次使用back鍵的情況: 在有back的地方,back,回到原來頁面,再back,重復多次,看會否出錯.

　　15. search檢查: 在有search功能的地方輸入系統存在和不存在的內容,看search結果是否正確.如果可以輸入多個search條件,可以同時添加合理和不合理的條件,看系統處理是否正確.

16. 輸入信息位置: 注意在光標停留的地方輸入信息時,光標和所輸入的信息會否跳到別的地方.

　　17. 上傳下載文件檢查：上傳下載文件的功能是否實現，上傳文件是否能打開。對上傳文件的格式有何規定，系統是否有解釋信息，并檢查系統是否能夠做到。

　　18. 必填項檢查：應該填寫的項沒有填寫時系統是否都做了處理，對必填項是否有提示信息，如在必填項前加*

　　19. 快捷鍵檢查：是否支持常用快捷鍵，如Ctrl+C Ctrl+V Backspace等，對一些不允許輸入信息的字段，如選人，選日期對快捷方式是否也做了限制。

　　20. 回車鍵檢查: 在輸入結束后直接按回車鍵,看系統處理如何,會否報錯。

 

網上關于Apache + JK + Tomcat的集群配置例子很多，按著例子配置下來，基本都能運行，不過，在一些重要的地方卻沒有進一步的說明。這次公司一個產品就是采用Apache+JK+Tomcat集群，在整個配置、測試過程中，遇到了許多的問題，經過不斷測試、摸索，最后總算是搞定了，性能也達到了預期的目標。針對網上的例子，感覺有必要再詳細的介紹一下我的配置過程，對一些要特別注意的地方進行補充。

集群有別于分布式的解決方案，它采用的是每臺服務器運行相同應用的策略，由負責平衡的服務器進行分流，這對提高整個系統的并發量及吞吐量是更有效的辦法。而集群對請求的處理又有兩種不同的方式：負載平衡、狀態復制(即集群)，狀態復制需要在各服務器間復制應用狀態，而負載平衡則不用，每臺服務器都是獨立的。實踐證明，在各應用服務器之間不需要狀態復制的情況下，負載平衡可以達到性能的線性增長及更高的并發需求。

對于集群的其它基礎知識，在此就不再做累贅。以下就這次Apache + JK + Tomcat的負載平衡配置進行總結，重點關注整個配置及注意事項。

準備軟件

1、 Tomcat或JBoss（本文檔中采用的是JBoss4.0.2）；

2、 apache2.0.54是開源的Web服務器，下載地址為： http://www.apache.org/dist/httpd/binaries/ ；

3、 mod_jk-1.2.14-apache-2.0.54.so模塊,jk是mod_jserv的替代者，它是Tomcat-Apache插件，為Apache和Tomcat的連接器，處理Tomcat和Apache之間的通信，在集群配置中充當負載均衡器的作用，當前的最新版本為1.2.15，不過不同JK版本與不同的Apache版本之間的搭配有一些差異，有的甚至配不起來。JK2是符合apache2.x系列的新品，但由于其配置太過麻煩，使用的人很少，所以目前已停止開發，所以我們采用了jk連接器，下載地址：http://www.apache.org/dist/tomcat/tomcat-connectors/jk/binaries/。

集群與負載平衡

使用mod_jk默認的以輪循方式進行平衡負載，假設有四個服務器節點，有10個請求，則四個節點分別接受請求編號如下：

而集群方式也是使用這種方法進行平衡。Tomcat中的集群原理是通過組播的方式進行節點的查找并使用TCP連接進行會話的復制。

    集群不同于負載平衡的是，由于集群服務需要在處理請求之間不斷地進行會話復制，復制后的會話將會慢慢變得龐大，因此它的資源占用率是非常高的，如果在并發量大的應用中，復制的會話大小會變得相當大，而使用的總內存更是會迅速升高。

    但集群的會話復制，增加了系統的高可用性。由于在每臺服務器都保存有用戶的Session信息，如果服務器群中某臺當機，應用可以自動切換到其它服務器上繼續運行，而用戶的信息不會丟失，這提高了應用的冗錯性。

具體采用負載平衡還是集群，這要看應用的需求了。

安裝配置Apache

1、下載Apache的安裝程序apache_2.0.54-win32-x86-no_ssl.exe后，安裝很簡單，一路回車，就此略過。

2、安裝完畢后，將下載的mod_jk-1.2.14-apache-2.0.54.so復制到Apache安裝目錄下的modules子目錄中。

3、然后進入Apache安裝目錄下的conf子目錄中，打開httpd.conf配置文件，在最后插入以下一行：

Include conf/mod_jk.conf

4、 在conf子目錄下，建立一個新的配置文件：mod_jk.conf，此文件為Apache加載連接器的配置文件，文件名可修改，但要與httpd.conf中Include的文件名一致，內容如下：

# Load mod_jk module. Specify the filename

# of the mod_jk lib you’ve downloaded and

# installed in the previous section

#加載mod_jk模塊

LoadModule jk_module modules/mod_jk-1.2.14-apache-2.0.54.so

# Where to find workers.properties

JkWorkersFile conf/workers2.properties

# Where to put jk logs

JkLogFile logs/mod_jk.log

# Set the jk log level [debug/error/info]

JkLogLevel info

# Select the log format

JkLogStampFormat "[%a %b %d %H:%M:%S %Y] "

# JkOptions indicate to send SSL KEY SIZE,

JkOptions +ForwardKeySize +ForwardURICompat -ForwardDirectories

# JkRequestLogFormat set the request format

JkRequestLogFormat "%w %V %T"

# 請求分發配置，可以配置多項

JkMount /* loadbalancer

#關掉主機Lookup，如果為on，很影響性能，可以有10多秒鐘的延遲。
HostnameLookups Off

注：藍色加粗的兩行是重點，第一句是Apache加載JK模塊用的；第二句為配置哪些URL請求將由負載平衡器來處理。

5、 在conf子目錄下，建立一個新的配置文件：workers2.properties，此文件為負載平衡的配置文件，文件名不能修改，這是JK默認的名字，內容如下：

worker.list=loadbalancer

# Define the first node...

worker.server99.port=8009

worker.server99.host=192.168.11.99

worker.server99.type=ajp13

worker.server99.lbfactor=1

worker.server99.local_worker=1

worker.server99.cachesize=1000

worker.server99.cache_timeout=600

worker.server99.socket_keepalive=1

worker.server99.socket_timeout=0

worker.server99.reclycle_timeout=300

worker.server99.retries=3

# Define the second node...

worker.server202.port=8009

worker.server202.host=192.168.11.202

worker.server202.type=ajp13

worker.server202.lbfactor=1

worker.server202.local_worker=1

worker.server202.cachesize=1000

worker.server202.cache_timeout=600

worker.server202.socket_keepalive=1

worker.server202.socket_timeout=0

worker.server202.reclycle_timeout=300

worker.server202.retries=3

# Now we define the load-balancing behaviour

worker.loadbalancer.type=lb

worker.retries=3

worker.loadbalancer.balance_workers=server99 ,server202

worker.loadbalancer.sticky_session=true

worker.loadbalancer.sticky_session_force=true

注：以上定義了兩個worker，一個為server99，另一個為server202，定義了一個負載平衡服務器loadbalancer，其中標藍色的為重點配置項，相關的詳細說明可以看官方的網站文檔：http://tomcat.apache.org/connectors-doc/，其它節點的定義可以直接Copy，修改一下節點名及IP就好了。
A、worker.list=loadbalancer

設定工作的負載平衡器，各Tomcat節點不能加入此列表。

    B、worker.server99.lbfactor

負載平衡的權重比，如果此權重比越大，則分配到此節點的請求越多，如以上兩個節點的權重比為1:1，則為平均分配。

C、worker.loadbalancer.balance_workers=server99,server202

   指定此負載平衡器負責的Tomcat應用節點。

D、worker.loadbalancer.sticky_session=true

   此處指定集群是否需要會話復制，如果設為true，則表明為會話粘性，不進行會話復制，當某用戶的請求第一次分發到哪臺Tomcat后，后繼的請求會一直分發到此Tomcat服務器上處理；如果設為false，則表明需求會話復制。

E、worker.loadbalancer.sticky_session_force=true

   如果上面的sticky_session設為true時，建議此處也設為true，此參數表明如果集群中某臺Tomcat服務器在多次請求沒有響應后，是否將當前的請求，轉發到其它Tomcat服務器上處理；此參數在sticky_session=true時，影響比較大，會導致轉發到其它Tomcat服務器上的請求，找不到原來的session，所以如果此時請求中有讀取session中某些信息的話，就會導致應用的null異常。

6、Apache服務器的配置文件httpd.conf中，默認有三個參數對性能的影響比較大，但根據不同的性能要求，參數的表現又不一樣，太小并發提不上去，太大性能反而不好，建議根據項目的需要，實際做個測試，如并發要求800的話，可以設定為：

#一個連接的最大請求數量

MaxKeepAliveRequests　1000（值為0，則不限制數量）

#每個進程的線程數，最大1920。NT只啟動父子兩個進程，不能設置啟動多個進程

ThreadsPerChild　　　　1000（最大為1920）

#每個子進程能夠處理的最大請求數

MaxRequestsPerChild   1000（值為0，則不限制數量）

這三個參數要根據不同的需求，不同的服務器進行調整。

安裝配置Tomcat或JBoss

1、對于Tomcat或JBoss的安裝，這里不做說明，目前我們是采用Apache+JBoss，不過，JBoss也是用的Tomcat，所以這里的配置也是適合Tomcat的；

2、對于JBoss的配置，很簡單，只需要改兩個地方就可以了：

第一個地方：進入jboss-4.0.2\server\default\deploy\jbossweb-tomcat55.sar，打開server.xml，大約在第32行左右，有，在其中加入一個參數，變為：

第二個地方：進入jboss-4.0.2\server\default\deploy\jbossweb-tomcat55.sar\META-INF目錄，打開jboss-service.xml，大約在110行，有false，將其改為：

true

這里有一個需要特別注意的地方，JBoss的Tomcat中，關于AJP連接協議的默認配置，對于大并發量是不夠用的，要做一些修改，進入jboss-4.0.2\server\default\deploy\jbossweb-tomcat55.sar，打開server.xml，找到的地方，這里是定義AJP連接器的地方，它的配置中沒有maxThreads項，默認為200，我們可以做修改：

         emptySessionPath="true" enableLookups="false" redirectPort="8443"

         protocol="AJP/1.3" maxThreads="3000"/>

maxThreads的值要看你的并發量多大，設置太大也不好。

運行

至此，整個配置全部完成，注意一點是，在各JBoss節點，重啟或新增加一個JBoss節點時，需要重新啟動Apache，而對于服務器群中某個JBoss節點shutdown，Apache會自動偵測，不用重新啟動。

如果在運行過程中，群中的某個JBoss節點shutdown，則已登錄到此服務器上的用戶的請求將出錯，此服務器負責的session將丟失，但Apache會自動偵測到此服務器已shutdown，后繼的新請求將不會再引導到此節點。

對于負責請求分發的Apache服務器，需要消耗大量的CPU資源，因此如果在測試過程中出現一些Service Temporarily Unavailable或Server  has shut down the connection prematurely這樣的錯誤，這一般都是服務器配置不夠好引起的，或者是Apache、Tomcat、及應用中的某些配置不夠使用，這時候就要考慮換更好的機器或優化應用中的配置。

常見問題

一、cannot connect to server：無法連接到服務器。這種情況是服務器的配置有問題，服務器無法承受過多的并發連接了，需要優化服務器的配置：

如操作系統采用更高版本，如windows 2003 server，

優化tomcat配置：maxThreads="500" minSpareThreads="400" maxSpareThreads="450"

但是tomcat 最多支持500個并發訪問

優化apache配置：

ThreadsPerChild 1900

MaxRequestsPerChild  10000

二、 Action.c(10): Error -27791: Server  has shut down the connection prematurely

HTTP Status-Code=503 (Service Temporarily Unavailable)
一般都是由于服務器配置不夠好引起的，需要優化硬件和調整程序了。

三、無法處理請求：

當我們輸入 ***.do 命令后，apache卻返回錯誤信息，而連接tomcat卻沒有問題。原因是沒有把.do命令轉發給tomcat處理。解決方法如下：

在apache配置文件中配置如下內容：

JkMount /*.jsp loadbalancer

JkMount /*.do loadbalancer

Web壓力測試是目前比較流行的話題，利用Web壓力測試可以有效地測試一些Web服務器的運行狀態和響應時間等等，對于Web服務器的承受力測試是個非常好的手法。Web 壓力測試通常是利用一些工具，例如微軟的Web Application Stress、Linux下的siege、功能全面的Web-CT等等，這些都是非常優秀的Web壓力測試工具。

雖然這些工具給我們測試服務器承受能力帶來方便，但是它們的危害卻更是驚人，甚至于利用隨便一種比較全面的測試工具就可以對一臺小型的 Web服務器發動災難性的拒絕式攻擊。下面我就帶大家利用微軟的Web Application Stress進行一次Web壓力測試，其目的是為了讓大家看到它的巨大危害。

一、工具簡單介紹

Microsoft Web Application Stress Tool 是由微軟的網站測試人員所開發，專門用來進行實際網站壓力測試的一套工具。透過這套功能強大的壓力測試工具，您可以使用少量的客戶端計算機仿真大量用戶上線對網站服務所可能造成的影響，在網站實際上線之前先對您所設計的網站進行如同真實環境下的測試，以找出系統潛在的問題，對系統進行進一步的調整、設置工作。就是因為這些特性，才使它具備了D.O.S轟炸的功能。

小提示：D.O.S（拒絕服務攻擊）通過使你的服務計算機崩潰或把它壓跨來阻止你提供服務。簡單來說，就是讓你的計算機提供可能多的服務從而使你的計算機陷入崩潰的邊緣或崩潰。

二、工具簡單設置

打開Web Application Stress Tool，很簡潔的一個頁面（如圖1），上面是工具欄，左下方是功能選項，右下方是詳細設置選項。在對目標Web服務器進行壓力測試之前，先對它進行一些必要的設置。

圖1

1. 在“settings”的功能設置中（如圖2），一個是Stress level (threads)這里是指定程序在后臺用多少線程進行請求，也就是相當于模擬多少個客戶機的連接，更加形象的就是說設置多少轟炸的線程數。一般填寫 500～1000，因為這個線程數是根據本機的承受力來設置的，如果你對自己的機器配置有足夠信心的話，那么設置的越高，轟炸的效果越好。

圖2

2.在“Test Run Time”中來指定一次壓力測試需要持續的時間，分為天、小時、分、秒幾個單位級別，你根據實際情況來設置吧！

3.其余的選項不太重要，這里就不再浪費筆墨，朋友們可以自己嘗試一下設置。

三、壓力測試

工具介紹完了，下面來準備條件：這里與一個朋友商量好進行測試，他是單機上網，機器配置是CPU:Athlon XP2500+、內存512MB、硬盤80GB等，機器配置還不錯。他在機器上安裝了IIS，架設了一臺對外的Web服務器，Web服務中的程序是動網 7.0。我就利用壓力測試工具對這臺服務器進行測試。

步驟1：在工具中點右鍵，選擇Add命令，增加了一個新的測試項目：New script，對它進行設置，在主選項中的server中填寫要測試的服務器的IP地址。在下方選擇測試的Web連接方式，這里的方式Verb選擇 get，path選擇要測試的Web頁面路徑，這里填寫/Index.asp,即動網的首頁文件（如圖3）。

圖3

步驟2：在“Settings”的功能設置中將Stress level (threads)線程數設置為1000。完畢后，點工具中的灰色三角按鈕即可進行測試（如圖4）。測試完畢，等待朋友把任務管理器以及連接查看的截圖發過來！

圖4

攻擊開始后，朋友從任務管理器中可以看到CPU使用率已經達到100%，損耗率達到最大（如圖5）。在CMD窗口中使用命令netstat -an,可以看到我的IP地址在朋友服務器上的80端口進行了非常多的連接（如圖6）。而且它的Web網站已經打不開了，提示過多用戶連接，達到了跟 D.O.S攻擊一樣的目的。

圖5

圖6

試想，如果利用多臺肉雞對一臺服務器進行Web壓力測試，那么對這臺服務器來說將是滅頂之災，所以朋友們在使用它之前一定要慎重考慮。

以創建交易腳本為例，詳細的解釋一下使用LoadRunner進行壓力測試的過程。關于如何定義測試目標及每個步驟詳細的操作過程在操作手冊中有解釋，這里就不說了。

一、 使用VUGen錄制腳本

1、根據應用程序架構選擇相應的協議。一般象B/S的程序用單一的http協議就可以了。

2、開始錄制。根據所選協議的不同，出現的對話框不不同的。選擇http協議的話需要錄入url地址，在這步錄入需要測試的地址如https://www.alipay3.net。

3、錄制腳本：在一個腳本中，默認有三個動作：vuser_init Action vuser_end。通常把初始化操作放到vuser_init中，具體需要測試的操作放在Action中，vuser_end動作目前來說沒有什么用處。在創建交易腳本中，需要測試的操作包括創建支付寶交易、買家付款、賣家發貨、買家確認收貨。每一個操作都必須首先登陸才能進行。

4、添加事務：為了使錄制的腳本更易讀，錄制過程中要為每一個獨立的操作添加事務。比如說登陸、買家付款都放在一個單獨的事務中。特別注意，因為本次測試目標是每秒內總的交易數，所以需要分別給每一個測試腳本的Action操作都加上一個統一的事務，名稱都叫做“Action”，以便衡量是否可以達到目標。

5、添加驗證點：腳本錄制好后，在需要的地方加上驗證點，來檢測腳本是否執行成功。以登陸操作來說，在提交登陸的腳本后面，右擊鼠標，選擇Insert—NewStep，在出現的對話框中選擇Web Checks—Text Check，進行文字驗證，查找退出這兩個字是否出現。如果出現就說明登陸成功了。

6、根據需要對變量參數化：在登陸操作中需要參數化的值包括：URL，登陸帳號、登陸密碼。點擊工具欄的Param List按鈕可以創建參數。當新建一個參數后，LR會在當前腳本的目錄下自動創建一個文件存放參數的值。我們不要這個默認的文件名，把所有參數的文件名都修改為“D:\LrData\Email.dat”[文件路徑及名稱都是可以手工修改的]，這樣可以在多個腳本中共享相同的變量。

a)        url、登陸帳號、登陸密碼：這幾個參數都是手工在LR中輸入，然后保存到文件中。

b)        交易號：在查詢交易明細腳本中，會隨機的選取100個交易查看其明細。這種情況下，交易號直接從數據庫中取得比較方便。但是必須在本地安裝oracle客戶端。如果沒有裝oralce客戶端，可以首先登陸到PL/SQL中，查詢100個交易號，選中把查詢結果，選擇導出到CSV文件中。如下圖：

 

導出后，在LR中打開Param List，選中交易號這個參數，點擊Edit With NotePad按鈕，把csv文件的內容拷貝到這個里面即可。注意拷貝前需要用支持列編輯的文本工具打開csv文件，去掉前后的引號。保存文件成功后，在LR中就可以看到導出的交易號了。

7、在Vuser中運行腳本，確認腳本可以正常運行。

二、            使用Controller設置場景進行測試

1、創建場景：由于我們這次的測試目標是以每秒N個交易，所以選擇基于目標的場景。創建場景的同時，加入需要測試的腳本。

2、定義測試目標：

場景創建成功后，單擊Edit Scenario Goals定義測試目標。

在這個對話框中新建一個測試目標，類型為：Transactions per Second，事務名稱為我們統一定義的“Action”，事務數量根據需要設置。Vuser的數量設置從20到500。

3、設置運行時間：

也是在Edit Scenario Goals中，可以設置達到目標后再運行多少時間。

4、Run-Time Setting：(特別注意)

在VuGen中也有Run-Time Setting，但是在那里設置好的參數不會被帶到Controller中，需要重新設置。對每一個腳本都需要設置。

a)        Think Time：這個選為Ignore think time，否則結果中的事務響應時間很大，包含了這個思考時間。

b)        打開驗證點檢查功能：在Preferences選項中，給Enable Image and text check打勾，否則腳本執行時不會去檢查驗證點的。

c)        設置Action的迭代次數：在Run Logic中，單獨設置腳本中每個動作的執行次數。例如在查詢交易明細腳本中，需要模擬一次登陸，查詢10次明細的情況，就需要設置Action動作迭代10次。

5、添加需要監控的性能參數

這次我們測試的服務器是Linux，需要得到在各種壓力下服務器的負載情況。Linux的性能參數在場景中沒有默認被監控，所以需要手動添加。要監控Linux的資源，需要在服務器上運行一個叫做rstatd的進程，這個進程可以從網上下載。在服務器上啟動這個進程后，

在測試場景中，手工將Available Graphs的UNIX Resources拖動到右邊的視圖中，然后右擊，選擇Add Measurements，添加需要監視的服務器。

 

圖中，上面一個Add添加需要監視的服務器，下面的Add是用來添加需要監視的參數，包括Average Load等等。

6、運行場景，保存執行結果

運行時，需要選擇運行結果保存的路徑及文件。這些結果文件可以在Analysis中查看。

三、            查看運行結果

第二步場景運行結束后，通過菜單Results—Analysis Results打開運行結果。

在Analysis中，默認顯示以下類型的結果分析圖。

需要手工把Unix資源的圖打開，單擊上圖中的New Graph，出現下面的對話框。

選擇System Resources下的UNIX Resources，單擊Open Graph，就可以看到在場景中所監視的各個性能指標的曲線圖了。

點擊保存可以把結果保存為*.lrr的文件，下次可以直接通過Analysis打開。

四、            比較2次或者多次場景運行的結果

測試中，為了提高系統的性能，會修改代碼或者更改架構，這時候我們需要對修改前后的場景運行結果進行比較，通過一些性能指標的曲線圖比較直觀的了解系統的變化。

在Analysis中，通過菜單File—Cross With Result可以合并結果進行比較。

 

通過Add按鈕可以添加多個*.lrr文件進行結果的比較，點OK后會出現各個結果的比較圖。