衡量系统性能的常见指标

1.响应时间（Response time）　　　　

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

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

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

间。细分的目的是为了方便定位性能瓶颈出现在哪个节点上

2．吞吐量（Throughput）

络吞吐量。

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

4．点击数（Hits per second）

计算的，一次鼠标可能触发多个 http 请求，这需要结合具体的 Web 系统实现来计算。

5．并发用户数（Concurrent users）

能指标是否被满足。

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

　　　　通常指每秒成功的事务数，事务可以理解为完成一件事可能要经过几个小的步骤，这些小的步骤必须全部成功执行，才算成功 测试人员眼中的软件性能其实满足用户的性能需求，只有以下几种方案：

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

2．以空间换时间

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

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

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

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