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后会出现各个结果的比较图。