性能相关问题_系统调用应用服务器和调用数据库的效率

<一>:
解释常用的性能指标名称与具体含义

性能测试是通过测试工具模拟多种正常、峰值及异常负载条件来对系统的各项性能指标进行测试。验证软件系统是否能够达到用户提出的性能指标，发现系统中存在的性能瓶颈并加以优化。
性能指标分为两个方面：
系统指标：与用户场景和需求相关指标；
资源指标：与硬件资源消耗相关指标；

系统指标：
响应时间：即系统响应时间（Transaction Response Time），应用系统从发出请求到客户端接收到响应所消耗的时间，是用户视角最关心的软件性能业务体验。响应时间为网络响应时间与应用程序响应时间之和；
一般响应时间在2s内，用户会感觉比较满意；
在2s~5s之间，用户勉强能接受；
大于8s，用户就可能无法接受，从而刷新页面或者离开；
平均响应时间：所有请求花费的平均时间；
吞吐量：单位时间内系统能够处理的客户请求的数量，直接体现软件系统的性能承载能力，计算方式是完成的事务数除以时间；
并发用户数：并发主要是针对服务器而言，在同一时刻与服务器进行交互（指向服务器发出请求）的在线用户数；
在线用户数：某段时间内，用户访问系统的用户数，如多个用户在浏览网页，但没有对同时对服务器进行数据请求，需要与并发用户数区分开；
最大并发用户数：有两种理解方式一种是从业务的角度来模拟真实的用户访问，体现的是业务并发用户数，指在同一时间段内访问系统的用户数量。另一种是从服务器端承受的压力来考虑，这里的“并发用户数”指的是同时向服务器端发出请求的客户数，一般结合并发测试（Concurrency Testing）使用，体现的是服务端承受的最大并发访问数；
事务：可以看作是一个动作或是一系列动作的集合，例如登录，从登录开始到登录结束为一个事务。
TPS:Transaction per second，每秒钟系统能够处理的交易或者事务的数量，即服务器对客户请求的能力，是衡量系统处理能力的重要指标。
吞吐量：网络传输的数据量（处理客户的请求数）；
吞吐率：单位时间（可以是秒/分/时/天）内网络成功传输的数据量，如请求数/秒、页面数/秒；
点击数：Web Server收到的HTTP请求数；
点击率：HPS，每秒钟用户向Web Server提交的HTTP请求数；

资源指标：
硬件性能指标：CPU，内存Memory，磁盘I/O（Disk I/O），网络I/O（Network I/O） ；
中间件：常用的中间件如web服务器Tomcat,Weblogic web服务器，JVM（java虚拟机），ThreadPool线程池，JDBC数据驱动 ；
数据库指标：SQL，吞吐量，缓存命中率，连接数等；
JVM：Java虚拟机，为使java的代码可以编译运行在不同的平台上顺畅，仿真模拟各种计算机来实现 ；
前端指标 ：首次显示时间，页面数量，页面大小，网络startRender，firstRender等。前端的性能与后端的性能的不同点在于，前端是每个用户的直观的感受，如前端页面加载元素耗费的时间，而后端的性能关注点在于多用户使用系统时，服务器是否能够承受或者服务器的处理能力如何，能否以较好的响应时间响应；
Load：系统平均负载，特定时间间隔内运行进程数，Load与cpu核数一致；

<二>
简述性能测试步骤？

1.熟悉应用：了解应用的架构、功能逻辑；
2.需求分析：根据测试目的，细化需求；
3.测试准备：客户端准备、测试数据准备、测试脚本准备；
4.执行测试：监控测试客户端和服务器性能，监控服务器端应用情况;
客户端的系统资源（CPU、IO、Memory）情况；
服务端的系统资源（CPU、IO、Memory）情况；
服务器的JVM运行情况；
服务端的应用情况是否有异常；
响应时间、吞吐量等指标；
5.性能分析与调优：找出性能瓶颈，提高系统整体性能，满足用户需求；
6.编写测试报告：测试结束后，归档整理测试报告；

<三>
服务端性能分析都从哪些角度来进行？

从维度上划分，性能指标主要分为两大类，分别是业务性能指标和系统资源性能指标。

业务性能指标可以直观地反映被测系统的实际性能状况，常用的指标项有：
并发用户数；
事务吞吐率（TPS/RPS）；
事务平均响应时间；
事务成功率；

系统资源性能指标，主要是反映整个系统环境的硬件资源使用情况，常用的指标包括：
服务器：服务器的CPU平均使用率小于70%，内存使用率小于75%；
数据库：数据库连接数、数据库读写响应时长、数据库读写吞吐量等；
网络：网络吞吐量、网络带宽、网络缓冲池大小；
缓存（Redis）：静态资源缓存命中率、动态数据缓存命中率、缓存吞吐量等；
测试设备（压力发生器）：CPU 利用率、处理器队列长度、内存利用率、内存交换页面数、磁盘 IO 状态、网卡带宽使用情况等。

<四>
如何理解压力、负载、性能测试？

性能测试是一个较大的范围，实际上性能测试本身包含了强度、压力、负载等多方面的测试内容。

压力测试是对服务器的稳定性以及负载能力等方面的测试，是一种很平常的测试。增大访问系统的用户数量、或者几个用户进行大数据量操作都是压力测试。

负载测试是压力相对较大的测试，主要是测试系统在一种或者集中极限条件下的相应能力，是性能测试的重要部分。100个用户对系统进行连续半个小时的访问可以看作压力测试，那么连续访问8个小时就可以认为负载测试，1000个用户连续访问系统1个小时也可以看作是负载测试。

实际上压力测试和负载测试没有明显的区分。测试人员应该站在关注整体性能的高度上来对系统进行测试。

<五>
tps无法上升原因有哪些？

1.网络带宽
在压力测试中，有时候要模拟大量的用户请求，如果单位时间内传递的数据包过大，超过了带宽的传输能力，就会造成网络资源竞争，导致服务端接收到的请求数达不到服务端的处理能力上限。

2.连接池
可用连接数太少，造成请求等待。连接池一般分为服务器连接池（比如Tomcat）和数据库连接池（或者理解为最大允许连接数也行）。

3.GC
如果堆内存分配的不合理，就会导致频繁的gc，gc会导致线程暂停。尤其是fullgc，会造成线程长时间暂停。

4.数据库配置
高并发情况下，如果请求数据需要写入数据库且需要写入多个表的时候，数据库的最大连接数不够，或者写入数据的SQL没有索引，或没有主从分离、读写分离，就会导致数据库事务处理过慢，影响到TPS。

5.硬件资源
包括CPU（配置、使用率等）、内存（占用率等）、磁盘（I/O、页交换等）。

6.压力机
单机负载能力有限，如果需要模拟的用户请求数超过其负载极限，会影响TPS（这个时候就需要进行分布式压测来解决问题）。

<六>
如何识别性能瓶颈？

硬件上的性能瓶颈：
一般指的是CPU、内存、磁盘I/O 方面的问题，分为服务器硬件瓶颈、网络瓶颈（对局域网可以不考虑）、服务器操作系统瓶颈（参数配置）、中间件瓶颈（参数配置、数据库、web服务器等）。

应用软件上的性能瓶颈：
一般指的是应用服务器、web 服务器等应用软件，还包括数据库系统。
例如：中间件weblogic 平台上配置的JDBC连接池的参数设置不合理，造成的瓶颈。

应用程序上的性能瓶颈：
一般指的是开发人员新开发出来的应用程序（SQL语句、数据库设计、业务逻辑、算法等），例如，程序架构规划不合理，程序本身设计有问题（串行处理、请求的处理线程不够），造成系统在大量用户访问时性能低下而造成的瓶颈。

操作系统上的性能瓶颈：
一般指的是windows、UNIX、Linux等操作系统。例如，在进行性能测试，出现物理内存不足时，虚拟内存设置也不合理，虚拟内存的交换效率就会大大降低，从而导致行为的响应时间大大增加，这时认为操作系统上出现性能瓶颈。

网络设备上的性能瓶颈：
一般指的是防火墙、动态负载均衡器、交换机等设备。例如，在动态负载均衡器上设置了动态分发负载的机制，当发现某个应用服务器上的硬件资源已经到达极限时，动态负载均衡器将后续的交易请求发送到其他负载较轻的应用服务器上。在测试时发现，动态负载均衡器没有起到相应的作用，这时可以认为网络瓶颈。

性能测试出现的原因及其定位十分复杂，这里只是简单介绍常见的几种瓶颈类型和特征，而性能测试所需要做的就是根据各种情况因素综合考虑，然后协助开发人员、DBA、运维人员一起定位性能瓶颈。

<七>
性能测试常用的linux命令

top 用来监控linux的系统状况，是常用的性能分析工具，能够实时显示系统中各个进程的资源占用情况。

vmstat 用于显示虚拟内存、内核线程、磁盘、系统进程、I/O 块、中断、CPU 活动 等的统计信息。

netstat 用于监控进出网络的包和网络接口统计的命令行工具。

iostat 统计CPU使用情况,以及统计磁盘设备IO和磁盘分区IO的使用情况。

free 显示当前系统未使用的和已使用的内存数目，还可以显示被内核使用的内存缓冲区。

lsof 用于查看你进程打开的文件。

pidstat 用于监控全部或指定进程占用系统资源的情况,如CPU,内存、设备IO、任务切换、线程等。

strace 跟踪程序执行过程中产生的系统调用及接收到的信号，帮助分析程序或命令执行中遇到的异常情况。

perf Linux kernel自带的系统性能优化工具，用于查看热点函数。

<八>
如何设计性能测试场景？

并发测试：基础线程组（强调单位时间的并发，不存在绝对并发)。

基准测试：反复对比结果，验证调优结果是否通过（tps是否提升，响应时间是否下降）。

负载测试：持续不断地增加负载，发现性能瓶颈（阶梯加压线程组）。
并发用户模式的负载：不断增加并发用户数，发现瓶颈。
吞吐量模式的负载：不断增加每秒请求数（rps）对服务端施压，发现tps瓶颈。

压力测试：tps瓶颈点上持续负载
稳定性压力测试：tps保持高压稳定。一般取最大tps的80%持续运行。
破坏性压力测试：目的是只需要服务端出现异常。

失效恢复测试：出现异常之后，系统可以很快的恢复。

容量规划测试：如果计算出集群当前的负荷快达到极限处理能力时，我们可以垂直扩展(加CPU/内存/磁盘)和水平扩展(加机器)两种方式来增加集群容量。

<九>
如何规避IO负载过高？

如果服务器用来做日志分析，注意随机读和顺序写，避免定期的压缩、解压大日志。
如果是前端应用服务器，要避免程序频繁打本地日志、或者异常日志。
如果是存储服务（mysql、nosql），尽量将服务部署在单独的节点上，做读写分离降低压力。