1.响应时间（Response time）　　　　

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

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

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

　　（3）客户端响应时间，这是客户端在构建请求和展现交易结果时所耗费的时间，对于普通的瘦客户端 Web 应用来说，这个时间很短，通常可以忽略不计；但是对于胖客户端 Web应用来说，比如 Java applet、AJAX，由于客户端内嵌了大量的逻辑处理，耗费的时间有可能很长，从而成为系统的瓶颈，这是要注意的一个地方。那么客户感受的响应时间其实是等于客户端响应时间+服务器端响应时间+网络响应时间。细分的目的是为了方便定位性能瓶颈出现在哪个节点上

2．吞吐量（Throughput）

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

3．资源使用率（Resource utilization）
　　　常见的资源有：CPU 占用率、内存使用率、磁盘 I/O、网络 I/O。

4．点击数（Hits per second）

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

5．并发用户数（Concurrent users）

　　并发用户数用来度量服务器并发容量和同步协调能力。在客户端指一批用户同时执行一个操作。并发数反映了软件系统的并发处理能力，和吞吐量不同的是，它大多是占用套接字、句柄等操作系统资源。另外，度量软件系统的性能指标还有系统恢复时间等，其实凡是用户有关资源和时间的要求都可以被视作性能指标，都可以作为软件系统的度量，而性能测试就是为了验证这些性能指标是否被满足。

6.TPS（Transaction Pre Second） 每秒完成的事务数

　　　　通常指每秒成功的事务数，事务可以理解为完成一件事可能要经过几个小的步骤，这些小的步骤必须全部成功执行，才算成功 测试人员眼中的软件性能用户恨不得让软件有无线的性能，但作为技术人员，我们需认识到，那种理想化的要求时不可能的。软件性能方案充满了辩证的各种矛盾。每种方案和方法几乎都有利有弊。只有把握设计系统的具体环境，明确设计目标，具体问题具体分析，合理平衡各种矛盾，牢牢抓住主要矛盾，才能产生出优化的软件系统性能方案。那么其实满足用户的性能需求，只有以下几种方案：

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

2．以空间换时间

　　软件的高性能并不是凭空产生的，在解决了空间和时间浪费的问题之后，如果用户还有更高的性能要求，我们软件人员只好“偷梁换柱”，做一下调整，而这种调整往往是很灵活的。空间换时间是软件人员解决性能问题最常见的方法。是在系统功能正常的前提下增大软件空间开销的方法来缩减运行的时间。一般的方法有算法调整、并行计算方法、体系结构方法和一些不是“办法”的办法。通常的解决方案有 Cache 缓存、数据库的 index 等。

3．以时间换空间
　　时间换空间的方案解决性能问题的情形比较少。有时会出现在对内存要求十分苛刻的地方，比如嵌入式操作系统中。以上是我们从简单的程序例子来理解性能解决方案，但现实要远远复杂得多，因为随着软件系统功能的复杂强大，软件的规模也在不断扩大，我们不可能完全自己开发程序，很多时候是利用已有的平台和中间件资源。在这种场景下，我们应该怎样考虑性能问题呢？

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

　　软件在设计阶段一旦决定采用哪种架构和技术，其性能也就注定只能在一定的范围内变动了。这就是“先天”因素。比如在上节讲到的一个删除/增加数据的业务操作，如果用户对时间非常苛刻，密集型计算、在线的大数据量统计和分析等应用，这些场景通常 J2EE 不能够很好地解决，使用 C++或者其他平台搭建会更合理些。如果在这些场景下硬要采用 J2EE架构，那么开发和设计人员如何绞尽脑汁，优化设计和程序，也不会满足用户的性能要求。
第二，中间件的设置和优化
　　这里的中间件是广义的中间件，是应用程序调用的第三方软件，包括操作系统、数据库、Web 服务器、消息服务器等。我们不能改变中间件的程序，只能通过调优手段来提高它所支持的软件系统的性能。
第三，硬件的配置
　　这里包括服务器硬件配置和网络环境。服务器硬件包括内存、CPU 等，网络环境有交换机、路由器等。