【IT168 技术文档】当今，计算机和软件工程发展越来越快，新的概念名词和技术手段层出不穷，可谓日新月异。在软件性能测试范畴内就有很多，诸如并发测试、压力测试、基准测试、测试场景等概念和名词，这让刚接触性能测试的新手眼花缭乱，目不暇接。但我们如果能深入软件性能测试的本质，从哲学的角度看问题，找出其内在联系，比如因果关系、形式内容关系，甚至重叠关系等，理清思路之后，那么做软件性能测试就会如庖丁解牛，游刃有余。

　　1.1 什么是软件的性能

　　1.1.1 软件

　　计算机软件作为人类逻辑智慧的结晶，它可以模拟并替代人类的一些活动，替人“发号施令”。在计算机软件发展的短短几十年内，计算机软件以非常快的速度渗透到了人类社会的各个角落，比如现在我们在家上网，出门坐公交车刷卡，在工作中发电子邮件等，这些生活的背后都有大量的软件系统运行支持。

　　同时，有关软件的概念和名词也呈爆炸性增长，从google中搜索“软件”关键词，就有135 000 000条记录;软件的方向和领域也在不断细化，比如软件架构和平台、软件工程、软件应用，还有软件开发测试等，因此我们可以判断软件的发展趋势是系统化、复杂化，这个趋势使软件能够提供越来越强大的功能，但同时也为我们理解和把握软件带来困难。

　　但我们做事的原则应该是要把复杂的事情变简单，而不是更复杂，更难理解。当我们试图理解和分析一个复杂的事物的时候，最常用的方法是分而治之，就是要用一个或多个简单的概念去解释或描述这个复杂的事物，这符合我们人类的认知规律，人们对简单的概念能够理解，那么对简单进行综合和归纳，就形成了对复杂的认知。比如，我们想要让一个没有上过网的人明白什么是“电子邮件”，那就可以告诉他“通过网络发送的邮件”，当然他很有可能对“网络”也一头雾水，那么你可以继续向他解释“打鱼的网”。但在软件领域中，我们却经常搞不明白这个道理，一个刚入门有志于软件性能测试的菜鸟小心翼翼地向一个前辈高人请教什么是性能测试，前辈首先以威严的口气告诉他“性能测试是很复杂的”，然后徐徐道来“性能测试分为负载测试、压力测试、容量测试等”。到这里，我相信可怜的菜同学对性能测试已经更加糊涂了，他在请教问题之前，恐怕还能知道性能测试是测试软件性能的，在得到高手回答之后，他开始勤奋地请教google，没想到google回答他的是更多的名词概念(网上文章都是前辈仙人写的)。随着时间推移，菜同学升级成牛同学，他对性能测试名词概念烂熟于心(google功底深厚)，并且牛同学又牢牢坚持与时俱进的思想，独立创新了N个性能测试概念，并开始向一群小菜粉丝们讲经布道，于是上一幕的画面和对白又开始回放，只是演员变了……这只是一个假想的故事，故事的结局就是通过“学习”，性能测试不仅没有简单，反而越来越复杂了。我们要真正掌握性能测试，那就要避免这样的事情发生，从本质上认识软件性能和软件性能测试。

　　辩证唯物主义哲学认为，时间和空间是运动着的世间万物的存在形式。大到社会形态，小到个人的活动，都是在一定的空间和时间内进行的。

　　因此，我们在试图把一件事情表述清楚时，通常要抓住事情的几个关键要素：时间、空间(地点)、人物(主体)、事件。比如“旅行者的一次长途旅行在两个月内从北京到西藏”，这句话中包含了关键要素，其时间是两个月，空间是北京到西藏，人物是旅行者，发生的事件是旅行者在两个月时间范围内发生空间中的转移;又如“一场足球赛”，这个名词看起来简单，但仍清楚地隐含了三个要素，即：时间，通常是90分钟(如果没有加时赛和伤停补时);空间，足球场内;人物，足球运动员，事件就是在足球规则下可能发生的事情，如进球等。

　　计算机的出现是人类历史上一次伟大的革命，在哲学“物质”这个名词的外延中又多了一个新型事物——计算机软件。如果我们认识到计算机软件也是万物之一，分析其作为“物质”的性质也逃脱不了自然法则的“紧箍咒”，那么我们同样可以把软件作如下简单的理解：

　　主体：程序，是人类逻辑思维的物化，表现形式为一系列指令代码。

　　时间：即使计算机速度再快，任何软件程序每一段代码的运行都是需要时间的，例如从用户的感受来讲，就是程序将运行结果响应给用户的速度。

　　空间：软件运行的环境，以资源的方式存在，通常是软件以间接或直接的方式占用并使用硬件资源和其他软件资源。

　　硬件资源主要指运行该软件的硬件平台，有CPU、内存和存储系统等，如果软件是基于网络架构的，那么硬件还有网络硬件，如交换机、路由器等。

　　软件资源包括操作系统、开发平台、中间件和数据库等，它们以库文件和API的方式提供给应用软件使用。

　　事件：软件按照用户的要求运行，运行的同时必然要占用时间资源和空间资源。

　　由于软件代码是人的逻辑思想的表现，所以软件在设计思想和实现方法上也有很大差异。另外，随着软件的发展，产生了各种应用领域的软件，它们之间存在着千丝万缕的关系。从层次上看，有系统软件，应用软件和介于两者之间的中间件。因此一个软件的运行牵涉的因素很多，需要从各个方面分析。

　　1.1.2 软件性能的产生

　　用户能够看到的是软件越来越通用，功能越来越庞大，从哲学角度上看待软件本身，其发展是一个从简单到复杂，从低级到高级，从无序到有序的过程。

　　在计算机发展的初期，计算机软件对硬件有很强的依赖性，而且还没有广泛的通用性，只有少数的个人或机构才使用软件这个“奢侈品”，当时用户也没有软件性能的概念，通常为了实现软件的功能而不计一切代价。比如，1946年2月15日，世界上第一台通用电子数字计算机“埃尼阿克”(ENIAC)在美国研制成功。它当时由1.8万个电子管组成，是一台又大又笨重的机器，体重达30多吨，占地有两三间教室般大。它当时的运算速度仅为每秒5000次加法运算，在现在看来，它占用如此多的资源，又运行得如此慢，在当时却是相当了不起的成就，因为它已经实现了功能——能够做加法运算。可见初期的软件是简单的，当时用户的要求用现在的眼光来看真有点可怜巴巴，对软件的要求不高，只要能工作就OK了。

　　软件诞生后，短短几十年，软件业奇迹般的高速发展，逐渐走下了高高在上的神坛，广泛应用到人类社会的各个领域，用户也不再把软件看做神秘的玩意，而是普通的商品，开始从经济学的角度来考虑软件产品，这是一个意味深长的变化。讲经济就是要运用投入产出的关系分析和指导软件工程的各种活动和环节，软件运行不能以硬件不计成本为假设，要尽可能地少占用各种硬件资源，同时，软件运行的速度也要尽可能地快，每秒5000次加法运算是根本不可想象的，也是不可能被用户接受的。这些其实就是用户的最原始的性能需求。

　　1.1.3 功能与性能的关系

　　首先，软件的性能和功能的源头都是来自于用户的需求。

　　功能指的是在一般条件下软件系统能够为用户做什么，能够满足用户什么样的需求。拿一个电子邮件系统来讲，用户期望这个软件系统能够提供收发电子邮件、保存草稿、设置偏好等功能，只有这些功能实现了，用户才认为这是他想要的软件。但是随着软件市场竞争的激烈，软件技术的日益提高，系统能不能工作已经是一个最起码的门槛，能够“又好又快”才会得到用户的青睐，而性能则是衡量软件系统“好快”的一个重要考虑因素。“好”就是要为用户省钱，用最小的硬件成本运行软件系统;“快”就是软件响应时间要短，我们的用户都是急性子，最好一秒钟也不要等。简单地说，性能就是在空间和时间资源有限的条件下，软件系统还能不能工作。

　　如果把上面邮件的功能和性能需求量化，写成用户需求说明书可能是下面这个样子：

　　功能：

　　邮件系统能够支持收发以30种语言为标题和正文的邮件，并支持粘贴10MB的邮件附件。

　　性能：

　　邮件系统能够在2GB RAM/1GHz CPU的服务器上，支持10000注册用户，日均处理10000邮件，响应时间不超过5秒/封。

　　我们来对比一下功能需求说明和性能需求说明，发现两者有一些不同之处：

　　(1)功能需求中名词和动词多，描述软件主体和动作行为，比如“标题”、“正文”、“收发”、“粘贴”等;

　　(2)性能需求中对涉及容量和时间词汇多，如“2GB RAM服务器”、“1000注册用户”、“5秒/封”等。

　　相信我们的读者已经从上面的对比看出功能和性能的区别了，软件性能和功能区别的实质是，软件功能焦点在于软件“做什么”，关注软件物质“主体”发生的“事件”;而软件性能则关注于软件物质“做得如何”，这是综合“空间”和“时间”考虑的方案(资源和速度)，表现为软件对“空间”和“时间”的敏感度。认识到性能的这个基本特征对于性能测试人员非常重要，因为在下面的章节中我们将要通过多个“空间”和“时间”的组合，来揭开性能指标的实质和提高的办法。另外，我们也要认清一个事实，软件的性能实现是建立在功能实现的基础之上的。

　　这就像一个人首先要能跑，这是一个健康的人的正常功能，然后才能参加百米比赛，这就如对人身体的性能考验。而百米比赛隐含了两个要素：一个是运动员有一个一百米的运动空间;另一个是比赛，要跑得足够快，要在短时间内跑完。因此我们说百米比赛其实就是一个空间和时间的综合结果。

　　“空间”和“时间”是一个哲学中抽象层次较高的概念，在不同的应用范围有不同的诠释。那么在软件理论和实践中，我们怎样理解“空间”和“时间”呢?所谓“仁者见仁，智者见智”，下面我们就分别从用户的角度和软件人员的角度来看一下软件的性能。

　　1.1.4 用户眼里的软件性能

　　软件系统在满足用户强大的功能需求同时，架构和实现上也变得复杂，软件系统经过单机系统时代、客户机服务器系统时代，到现在跨广域网的庞大分布式系统时代，这样的例子在金融、电信系统中随处可见。

　　系统的业务量大了，就要使用更多的时间和空间资源，在一般情况下不能出现的软件性能问题就暴露出来了，这些问题“不鸣则已，一鸣惊人”，轻则让软件对外不能正常提供服务，重则可能会导致系统的崩溃甚至数据的丢失，这都会给用户带来无法估量的损失。

　　案例1

　　某西部大型油田使用钻井平台数据采集系统，在上线之前已经通过功能测试，但软件系统上线之后，在使用采集的电子数据勘探油层时，总是不能准确地找到油口，导致数百万元的损失。经过研究试验，发现软件从平台采集的数据和手工采集的数据有很大出入，性能测试后，找到根本原因：由于采集过程中产生的数据量非常大，导致软件系统在采集过程中线程死掉，丢失部分数据，最终产生的是一个错误的采集结果，为工程人员提供了错误的判断依据。

　　案例2

　　日本第三大手机运营商——软银移动2006年10月遇到了麻烦，本指望通过降低手机资费来吸引用户，谁想大量用户蜂拥而至却导致自己的电脑系统陷入瘫痪，软银移动在10月29日不得不宣布暂停接纳新的用户，直接损失逾亿日元。

　　用户当然不想看到以上的场景发生在自己的软件系统上，“瘫痪”意味着响应时间过长，不能为客户正常提供服务;数据丢失则是一个不可接受的严重问题，损失几乎不可弥补。因此用户对软件性能的要求日益细化严格，可以说是“与时俱进”。

　　简单地说，在软件发展的初级阶段，“又要马儿跑，又要马儿少吃草”，这是当时很多用户对软件系统提出的性能要求，“跑”有关时间，“草”有关空间。马儿跑，就是软件系统给用户的响应要快，处理时间要短;马儿少吃草就是软件系统能够尽可能地少占用和消耗资源，诸如内存、CPU等。因此，测试人员在做性能测试时，往往要把响应时间、内存利用率、I/O占用率等写在最后测试报告里，因为这是用户最关心的东西。

　　随着用户的软件质量意识的增强，用户对软件的性能需求也越来越多，越来越细致。这时不仅要让马儿跑，还要马儿能快能慢(软件系统的伸缩性)，“路遥知马力”(软件系统在长时间运行下的稳定性)等。细数起来，如下：
       计算性能;
      资源的利用和回收;
      启动时间;
      伸缩性;
      稳定性。

       计算性能——就是马儿要能跑，要有很快的速度，最好是“日行千里，夜行八百”。对软件系统来讲，计算性能是用户最关心的一个指标，即软件系统有多快。比如，用户会关注软件系统执行一个典型的业务需要花多少时间。我们要给出用户答案，我们的系统完成用户典型操作，比如业务的交易计算，数据的增、删、改、查时间是不是在用户可以接受的范围内。

　　资源的利用和回收——就是马儿少吃草。软件系统的“草料”就是其依存的硬件和软件资源，硬件资源包括客户端硬件、服务器硬件和网络硬件;软件资源包括操作系统、中间件和数据库等。其中要特别说的是，运行软件系统需要使用到的服务器内存数量，对于整个系统的性能表现是至关重要的。因此，软件系统能否在运行时有效地使用和释放内存是我们考察软件性能的一个重要因素。

　　对计算机来讲，计算机内存为程序提供运行空间(有代码区和数据区)，如果内存不够大，CPU就不能把全部的数据和程序放到内存里，只好放一部分在内存，一部分放在硬盘中，现用现取，而读取内存和读取硬盘数据的速度要差好几个数量级，这就大大影响了计算机的工作效率。如果还不能理解内存的重要性的话，可以用个形象的例子来说明：

　　如果CPU是个画家，那么内存就是他的工作台。工作台上放着画布(被操作的数据)，还有各种画笔、刷子等各种工具(运行的程序)。如果工作台(内存)不能足够大，容纳不下绘画所使用的所有工具，那么画家就需要不时地去储藏室(硬盘等存储设备)里取所需的工具，这就会大大影响绘画的速度。

　　所以在评价一个系统性能的时候，要特别关注这个系统对内存的使用。

　　启动时间——这是马儿的加速度问题。用户希望系统进入正常工作状态的时间越短越好，尤其在主备系统中，软件的启动时间直接影响主备的切换效率。而不同软件系统启动时间会不同的。J2EE系统在第一次启动的时候一般会比较慢，因为期间涉及缓存的加载、JSP页面的编译、Java class编译成机器指令等。所以在第一次启动应用感到非常慢是比较正常的，这也是J2EE或者Java应用的一个特点。而C/C++程序直接运行的是二进制机器代码，启动速度就要快一些。

　　伸缩性——马儿要能快能慢。伸缩性是分析系统性能经常被忽略的一个方面。比如一个系统在50个并发用户访问的时候表现正常，但是当并发用户达到1000的时候，系统表现如何?服务器的性能是逐渐下降呢，还是在某个拐点附近急剧下降呢?

　　如图1-1所示，该图是一个伸缩性不好的系统的表现，随着并发用户的增加，平均相应时间越来越长。系统最终会达到一个不可用的程度，没有一个用户会接受系统这样的性能表现。

　　图1-1 伸缩性不好的用户 - 响应时间图

　　如图1-2所示就是一个伸缩性较好的系统的表现，随着并发用户的增加，平均响应时间逐渐稳定下来。

　　图1-2 伸缩性良好的用户 - 响应时间图

　　稳定性——千里马能够“路遥知马力”，而黑马只能够一时跑得快。用户希望自己的软件系统是千里马，而不是黑马。尤其是金融和电信系统，这些系统基本上都是每天24小时运转，时时刻刻准备着为用户提供服务。如果它们在运行一段时间后出现了问题，不能响应用户的请求甚至破坏或丢失了数据，那么系统为用户带来的损失是巨大的。这种稳定性问题应该在软件系统上线之前就被考虑并得到解决。

　　“快”、“好”这只是用户的主观体验，如果能让这些感觉和要求被其他人正确地理解(尤其是对软件人员)，那么就需要用数据把上述用户的感受量化并表达出来，这就是性能指标。

　　通常，衡量一个软件系统性能的常见指标有：

　　1.响应时间(Response time)

　　响应时间就是用户感受软件系统为其服务所耗费的时间，对于网站系统来说，响应时间就是从点击了一个页面计时开始，到这个页面完全在浏览器里展现计时结束的这一段时间间隔，看起来很简单，但其实在这段响应时间内，软件系统在幕后经过了一系列的处理工作，贯穿了整个系统节点。根据“管辖区域”不同，响应时间可以细分为：

　　(1)服务器端响应时间，这个时间指的是服务器完成交易请求执行的时间，不包括客户端到服务器端的反应(请求和耗费在网络上的通信时间)，这个服务器端响应时间可以度量服务器的处理能力。

　　(2)网络响应时间，这是网络硬件传输交易请求和交易结果所耗费的时间。

　　(3)客户端响应时间，这是客户端在构建请求和展现交易结果时所耗费的时间，对于普通的瘦客户端Web应用来说，这个时间很短，通常可以忽略不计;但是对于胖客户端Web应用来说，比如Java applet、AJAX，由于客户端内嵌了大量的逻辑处理，耗费的时间有可能很长，从而成为系统的瓶颈，这是要注意的一个地方。

　　那么客户感受的响应时间其实是等于客户端响应时间+服务器端响应时间+网络响应时间。细分的目的是为了方便定位性能瓶颈出现在哪个节点上(何为性能瓶颈，下一节中介绍)。

　　2.吞吐量(Throughput)

　　吞吐量是我们常见的一个软件性能指标，对于软件系统来说，“吞”进去的是请求，“吐”出来的是结果，而吞吐量反映的就是软件系统的“饭量”，也就是系统的处理能力，具体说来，就是指软件系统在每单位时间内能处理多少个事务/请求/单位数据等。但它的定义比较灵活，在不同的场景下有不同的诠释，比如数据库的吞吐量指的是单位时间内，不同SQL语句的执行数量;而网络的吞吐量指的是单位时间内在网络上传输的数据流量。吞吐量的大小由负载(如用户的数量)或行为方式来决定。举个例子，下载文件比浏览网页需要更高的网络吞吐量。

　　3.资源使用率(Resource utilization)

　　常见的资源有：CPU占用率、内存使用率、磁盘I/O、网络I/O。

　　我们将在Analysis结果分析一章中详细介绍如何理解和分析这些指标。

　　4.点击数(Hits per second)

　　点击数是衡量Web Server处理能力的一个很有用的指标。需要明确的是：点击数不是我们通常理解的用户鼠标点击次数，而是按照客户端向Web Server发起了多少次http请求计算的，一次鼠标可能触发多个http请求，这需要结合具体的Web系统实现来计算。

　　5.并发用户数(Concurrent users)

　　并发用户数用来度量服务器并发容量和同步协调能力。在客户端指一批用户同时执行一个操作。并发数反映了软件系统的并发处理能力，和吞吐量不同的是，它大多是占用套接字、句柄等操作系统资源。

　　另外，度量软件系统的性能指标还有系统恢复时间等，其实凡是用户有关资源和时间的要求都可以被视作性能指标，都可以作为软件系统的度量，而性能测试就是为了验证这些性能指标是否被满足。

　　1.1.5 软件人员眼里的软件性能

　　用户恨不能让软件有无限的性能，但作为软件技术人员，我们需清楚地认识到，那种理想化的要求是不可能的。在软件性能方案中，没有什么功能较多钥匙，软件性能方案充满了辩证的各种矛盾。每种方案和方法几乎都有利有弊。只有把握设计系统的具体环境，明确设计目标，具体问题具体分析，合理平衡各种矛盾，牢牢抓住主要矛盾，才能产生出优化的软件系统性能方案。

　　在上面的分析中，我们得知软件性能是软件运行空间和时间综合考虑的解决方案。那么其实满足用户的性能需求，只有以下几种方案：

　　1.消除软件对空间和时间不必要的浪费

　　一个最明显的例子就是内存泄漏问题，它被开发人员看做是大忌。

　　严格地说，内存泄漏应该属于软件程序设计的一种缺陷，该缺陷直接导致了程序在运行过程中无法释放不再需要的内存空间，从而造成内存资源浪费，严重的会造成无可用内存，导致系统崩溃。具体来说，当用户程序在运行过程中需要动态获得内存时，操作系统总是从堆(heap)上分配相应的空间给应用，分配的结果是将该堆内存的起始地址通过指针返回给应用。正常情况下，使用完这块内存后，应通过系统调用主动通知操作系统回收这些堆内存以便重用。但是，如果由于设计缺陷导致在某些情况下程序没有主动地通知到操作系统，而后应用又失去了对这块内存的引用时，则该堆内存块将成为既不受程序控制，又不能被系统回收重用的“孤儿”内存，这便是我们所指的内存泄漏。

　　案例1

　　void foo( )

　　{

　　char *str;

　　str = (char*)malloc(32*sizeof(char));

　　strcpy(str, "hello world");

　　return;

　　/* str所指向的32个字节的内存没有被释放，当foo()返回时造成内存泄漏 */

　　}

　　解决：C语言中malloc和free函数要配对使用。

　　案例2

　　void foo()

　　{

　　//定义string1指针，其指向一个堆上的100个字节的内存空间

　　char *string1 = (char*)malloc(100*sizeof(char));

　　//定义string2指针，其指向一个堆上的200个字节的内存空间

　　char *string2 = (char*)malloc(200*sizeof(char));

　　scanf("%s", string2);

　　string1=string2;/*string1原先指向的100个字节的内存没有被释放*/

　　/*而后又被指向string2所指的内存块，造成前面100个字节的内存泄漏*/

　　free(string2);

　　free(string1); /* 这个free()调用会失败，因为string1指向

　　的内存地址与string2的相同，而那块内存已经被释放了 */

　　return 0;

　　}

　　解决：在程序堆上分配内存后，要在使用完后及时释放，同时避免野指针的产生，比如string1。

　　原理：内存是软件运行的重要的空间资源，内存泄漏实际上是浪费了软件的空间资源。因此，内存泄漏对软件的性能影响十分重要。

　　另外，对于程序在时间上的浪费，我们通常是采用优化算法和数据结构的解决策略。

　　案例3

　　最近几年，很多知名软件公司在招聘软件测试人员，考察代码能力的时候，内存泄露和算法优化是经常的试题之一。这说明了用户对软件性能的要求越来越严格，已经传递到了软件公司。

　　2.以空间换时间

　　软件的高性能并不是凭空产生的，在解决了空间和时间浪费的问题之后，如果用户还有更高的性能要求，我们软件人员只好“偷梁换柱”，做一下调整，而这种调整往往是很灵活的。

　　空间换时间是软件人员解决性能问题最常见的方法。是在系统功能正常的前提下增大软件空间开销的方法来缩减运行的时间。一般的方法有算法调整、并行计算方法、体系结构方法和一些不是“办法”的办法。

　　通常的解决方案有Cache缓存、数据库的index等。

　　案例4

　　一个动态网站服务器总发生CPU耗尽的问题，因此造成给用户的响应缓慢或者长时间没有响应，进而引起Server的宕机。经调查分析，网站首页是个PHP程序，每次用户访问都要多次查询数据库，也没有Cache机制，数据库查询负荷过高，耗尽CPU。

　　解决：改写网站首页以及部分频繁访问的程序，增加Cache机制，减少数据库访问。

　　原理：将常用数据放在服务器的内存中，虽然增加了内存的开销，但带来了时间上的优化，对用户而言，提高了处理速度。

　　3.以时间换空间

　　时间换空间的方案解决性能问题的情形比较少。有时会出现在对内存要求十分苛刻的地方，比如嵌入式操作系统中。

　　案例5

　　程序设计的要求是不设中间变量，交换两个变量的值。

　　我们通常的中间变量的解决方案是：

　　Void swapOne(int *a, int *b)

　　{

　　Int temp;

　　Temp = *a;

　　*a = *b;

　　*b= temp;

　　}

　　但这里需要在程序中为temp变量在栈上分配一个空间。可不可以不用这个temp变量呢?

　　解决：

　　修改程序如下：

　　void swapTwo(int *a,int *b)

　　{

　　*a=*a+*b;

　　*b=*a-*b;

　　*a=*a-*b;

　　}

　　原理：修改之后，多了运算复杂度，但没有使用第三方变量，减少了空间的占用。

　　以上是我们从简单的程序例子来理解性能解决方案，但现实要远远复杂得多，因为随着软件系统功能的复杂强大，软件的规模也在不断扩大，我们不可能完全自己开发程序，很多时候是利用已有的平台和中间件资源。在这种场景下，我们应该怎样考虑性能问题呢?

　　第一，软件系统设计的架构及技术平台

　　软件在设计阶段一旦决定采用哪种架构和技术，其性能也就注定只能在一定的范围内变动了。这就是“先天”因素。比如在上节讲到的一个删除/增加数据的业务操作，如果用户对时间非常苛刻，密集型计算、在线的大数据量统计和分析等应用，这些场景通常J2EE不能够很好地解决，使用C++或者其他平台搭建会更合理些。如果在这些场景下硬要采用J2EE架构，那么开发和设计人员如何绞尽脑汁，优化设计和程序，也不会满足用户的性能要求。

　　第二，中间件的设置和优化

　　这里的中间件是广义的中间件，是应用程序调用的第三方软件，包括操作系统、数据库、Web服务器、消息服务器等。我们不能改变中间件的程序，只能通过调优手段来提高它所支持的软件系统的性能。

　　第三，硬件的配置

　　这里包括服务器硬件配置和网络环境。服务器硬件包括内存、CPU等，网络环境有交换机、路由器等。