1. 什么是负载测试？什么是性能测试？
压力测试通常是在高负载情况下来对系统的稳定性进行测试，更有效地发现系统稳定性的隐患和系统在负载峰值的条件下功能隐患等。
性能测试：指在一定的约束条件下（指定的软件、硬件、网络环境等），确定系统所能承受的最大负载压力。
2.
性能测试包含负载测试、压力测试、大数据量测试、疲劳强度测试等。
3.
第二，分析应用场景和用户数据，细分用户行为和相关的数据流，确定测试点或测试接口，列示系统接口的可能瓶颈，一般是先主干接口再支线接口，并完成初步的测试用例设计。
第三，依据性能测试需求和确定的测试点进行测试组网设计，并明确不同组网方案的重要程度或优先级作为取舍评估的依据，必要时在前期产品设计中提出支持性能测试的可测试性设计方案和对测试工具的需求。
第四，完成性能测试用例设计、分类选择和依据用户行为分析设计测试规程，并准备好测试用例将用到的测试数据。
在进行性能测试的时候，我们需要知道一些有效的性能指标，下面我们来列出一些主要的性能指标：
一是，通用指标（指Web应用服务器、数据库服务器必需测试项）：
4.
A4：制定性能测试计划—>开发测试脚本—>设计测试场景—>执行测试场景—>监控测试场景—>分析测试结果
5.
功能测试通过；一般需要进行性能测试的系统，都是用户量比较大、业务使用比较频繁、比较重要的功能模块。
6.
A6：主要有三部分组成：
7.
8.
LoadRunner的Controller组件。
9.
10.
设置场景：选择场景类型、设置运行时设置、模拟用户数、加减压方式、持续时间，配置负载生成
1.选择场景中需要的脚本
用户登陆，
客户端发送请求后，服务端验证正确性后，发送给客户端sessionid，是某种规则产生。
两地方可以设置
1.设置允许录制时进行自动关联，可以自定义规则
2.录制完成后，vuser-scan action for correlations
Run-time，log，
当调试脚本时，可以只输出错误日志，当在场景找你管加载脚本时，日志自动变为不可用。
Standard Log Option：选择标准日志时，就会在脚本执行过程中，生成函数的标准日志并且输出信息，供调试用。大型负载测试场景不用启用这个选项。
扩展日志包括警告和其他信息。大型负载测试不要启用该选项。用扩展日志选项，可以指定哪些附加信息需要加到扩展日志中
VuGen有两个选项帮助调试Vuser脚本。Run Step by Step命令和断点（breakpoints）。Option对话框中的调试设置（Debug
lr_set_debug_messag函数在脚本中手工设置信息类型。如果我们只想接收到一小段脚本的调式信息。
在创建用户自定义函数前我们需要和创建DLL（external libary）。把库放在VuGen bin目录下。一旦加了库，把自定义函数分配做一个参数。该函数应该具有一下格式：__declspec (dllexport) char* (char*, char*)。
Milan
Ramp up这个选项用于逐渐增加服务器的虚拟用户数或负载量。设置一个初始值而且可以在两个迭代之间设置一个值等待。设置Ramp up，请到‘Scenario Scheduling Options’。
VuGen提供了用多线程的便利。这使得在每个生成器上可以跑更多的虚拟用户。如果是以进程的方式跑虚拟用户，为每个用户加载相同的驱动程序到内存中，因此占用了大量的内存。这就限制了在单个生成器上能跑的虚拟用户数。如果按线程运行，给定的所有虚拟用户数（比如100）只是加载一个驱动程序实例到内存里。每个线程共用父驱动程序的内存，因此在每个生成器上可以跑更多的虚拟用户。
lr_abort函数放弃虚拟用户脚本的执行。说明虚拟用户停止Action的执行，直接执行vuser_end然后结束执行。在出现错误情况下想手工放弃脚本的执行，这个函数是有用的。用这个函数停止脚本时，Vuser被指定为“Stopped”状态。为了这个函数起作用，开始时候就不能选择Run-Time Settings中的Continue on error选项。
吞吐量图显示的是虚拟用户每秒钟从服务器接收到的字节数。当和响应时间比较时，可以发现随着吞吐量的降低，响应时间也降低，同样的，吞吐量的峰值和最大响应时间差不多在同时出现。
通过Web资源监视器，利用这些监控器可以分析web服务器的吞吐量、点击率、每秒http响应数以及每秒下载的页面数。
思考时间是真实用户在action之间等待的时间。例如：当一个用户从服务器接收到数据时，用户可能需要在响应之前等待几分钟回顾数据，这种推迟被称为思考时间。
Standard Log Option：选择标准日志时，就会在脚本执行过程中，生成函数的标准日志并且输出信息，供调试用。大型负载测试场景不用启用这个选项。
扩展日志包括警告和其他信息。大型负载测试不要启用该选项。用扩展日志选项，可以指定哪些附加信息需要加到扩展日志中
Lr_debug_message
lr_debug_message 函数在指定的消息级别
// 处于活动状态时发送一条调试消息。如果指定的
// 消息级别未处于活动状态，则不发出消息。
Lr_output_message
要发送不是特定错误消息的特殊通知，
Lr_error_message
函数将错误消息发送到
// 输出窗口和 Vuser日志文件
Lrd_stmt lrd_exec 函数执行 lrd_stmt设置的
Lrd_fetch
result set.
函数准备用于
// 通过光标输出字符串（通常为 SQL语句）
// 的下一结果集。对于 CtLib，它发出 ct_result
// 命令，并且在 ODBC中它运行用于当前数据库
单位时间内系统处理客户端的请求数。
1.小用户量的情况下测试
2.大用户量情况下的测试
分析的方法：
整个系统架构分析，系统响应时间消耗，利用图表分析
查看事务响应时间，通过事务摘要图分析事务响应时间，那个消耗最大（通过小用户量和大用户量的响应时间分析，查看那个事务响应时间最高），确定哪部分功能是性能的瓶颈，分析window resource图表，查看cpu
使用下列计数器标识cpu瓶颈
Processor\ Interrupts/sec
Processor\ % Processor Time
Process(process)\ % Processor Time
System\ Processor Queue Length
通过它来确定是否硬件本身出现瓶颈，或者进一步确定应该怎么去判断性能产生瓶颈的地方！
下一步去判断进程，那个进程消耗cpu最高
下边就有很多种情况需要你自己去判断，有可能是进程调用了的函数消耗了系统资源形成上边的问题，也有可能是后台数据库出现的问题（这个就要看你的系统配置是什么样的，比如你的db服务器和应用服务器都配置在一台机器上）
性能产生瓶颈有很多地方，所以需要进一判断，是否是后台数据库的问题还有待分析，是那条语句导致的问题需要进一步分析判断。
分析原则：
• 具体问题具体分析（这是由于不同的应用系统，不同的测试目的，不同的性能关注点）
• 查找瓶颈时按以下顺序，由易到难。
服务器硬件瓶颈-〉网络瓶颈（对局域网，可以不考虑）-〉服务器操作系统瓶颈（参数配置）-〉中间件瓶颈（参数配置，数据库，web服务器等）-〉应用瓶颈（SQL语句、数据库设计、业务逻辑、算法等）
注：以上过程并不是每个分析中都需要的，要根据测试目的和要求来确定分析的深度。对一些要求低的，我们分析到应用系统在将来大的负载压力（并发用户数、数据量）下，系统的硬件瓶颈在哪儿就够了。
• 分段排除法很有效
分析的信息来源：
•1 根据场景运行过程中的错误提示信息
•2 根据测试结果收集到的监控指标数据
一．错误提示分析
分析实例：
1 •Error: Failed to connect to server “10.10.10.30:8080″: [10060] Connection
•Error: timed out Error: Server “10.10.10.30″ has shut down the connection prematurely
分析：
•A、应用服务死掉。
（小用户时：程序上的问题。程序上处理数据库的问题）
•B、应用服务没有死
（应用服务参数设置问题）
例：在许多客户端连接Weblogic应用服务器被拒绝，而在服务器端没有错误显示，则有可能是Weblogic中的server元素的 AcceptBacklog属性值设得过低。如果连接时收到connection refused消息，说明应提高该值，每次增加25％
•C、数据库的连接
(1、在应用服务的性能参数可能太小了 2、数据库启动的最大连接数（跟硬件的内存有关）)
2
分析：可能是以下原因造成
•A、应用服务参数设置太大导致服务器的瓶颈
•B、页面中图片太多
•C、在程序处理表的时候检查字段太大多
二．监控指标数据分析
1．最大并发用户数：
应用系统在当前环境（硬件环境、网络环境、软件环境（参数配置））下能承受的最大并发用户数。
在方案运行中，如果出现了大于3个用户的业务操作失败，或出现了服务器shutdown的情况，则说明在当前环境下，系统承受不了当前并发用户的负载压力，那么最大并发用户数就是前一个没有出现这种现象的并发用户数。
如果测得的最大并发用户数到达了性能要求，且各服务器资源情况良好，业务操作响应时间也达到了用户要求，那么OK。否则，再根据各服务器的资源情况和业务操作响应时间进一步分析原因所在。
2．业务操作响应时间：
• 分析方案运行情况应从平均事务响应时间图和事务性能摘要图开始。使用“事务性能摘要”图，可以确定在方案执行期间响应时间过长的事务。
• 细分事务并分析每个页面组件的性能。查看过长的事务响应时间是由哪些页面组件引起的？问题是否与网络或服务器有关？
• 如果服务器耗时过长，请使用相应的服务器图确定有问题的服务器度量并查明服务器性能下降的原因。如果网络耗时过长，请使用“网络监视器”图确定导致性能瓶颈的网络问题
3．服务器资源监控指标：
内存：
1 UNIX资源监控中指标内存页交换速率（Paging rate），如果该值偶尔走高，表明当时有线程竞争内存。如果持续很高，则内存可能是瓶颈。也可能是内存访问命中率低。
2 Windows资源监控中，如果Process\Private Bytes计数器和Process\Working Set计数器的值在长时间内持续升高，同时Memory\Available bytes计数器的值持续降低，则很可能存在内存泄漏。
内存资源成为系统性能的瓶颈的征兆:
很高的换页率(high pageout rate);
进程进入不活动状态;
交换区所有磁盘的活动次数可高;
可高的全局系统CPU利用率;
内存不够出错(out of memory errors)
处理器：
1 UNIX资源监控（Windows操作系统同理）中指标CPU占用率（CPU utilization），如果该值持续超过95%，表明瓶颈是CPU。可以考虑增加一个处理器或换一个更快的处理器。如果服务器专用于SQL Server,可接受的最大上限是80-85%
合理使用的范围在60%至70%。
2 Windows资源监控中，如果System\Processor Queue Length大于2，而处理器利用率（Processor Time）一直很低，则存在着处理器阻塞。
CPU资源成为系统性能的瓶颈的征兆:
很慢的响应时间(slow response time)
CPU空闲时间为零(zero percent idle CPU)
过高的用户占用CPU时间(high percent user CPU)
过高的系统占用CPU时间(high percent system CPU)
长时间的有很长的运行进程队列(large run queue size sustained over time)
磁盘I/O：
1 UNIX资源监控（Windows操作系统同理）中指标磁盘交换率（Disk rate），如果该参数值一直很高，表明I/O有问题。可考虑更换更快的硬盘系统。
2 Windows资源监控中，如果 Disk Time和Avg.Disk Queue Length的值很高，而Page Reads/sec页面读取操作速率很低，则可能存在磁盘瓶径。
I/O资源成为系统性能的瓶颈的征兆 :
过高的磁盘利用率(high disk utilization)
太长的磁盘等待队列(large disk queue length)
等待磁盘I/O的时间所占的百分率太高(large percentage of time waiting for disk I/O)
太高的物理I/O速率:large physical I/O rate(not sufficient in itself)
过低的缓存命中率(low buffer cache hit ratio(not sufficient in itself))
太长的运行进程队列，但CPU却空闲(large run queue with idle CPU)
4．数据库服务器：
SQL Server数据库：
1 SQLServer资源监控中指标缓存点击率（Cache Hit Ratio），该值越高越好。如果持续低于80%，应考虑增加内存。
2 如果Full Scans/sec（全表扫描/秒）计数器显示的值比1或2高，则应分析你的查询以确定是否确实需要全表扫描，以及SQL查询是否可以被优化。
3 Number of Deadlocks/sec(死锁的数量/秒)：死锁对应用程序的可伸缩性非常有害，并且会导致恶劣的用户体验。该计数器的值必须为0。
4 Lock Requests/sec(锁请求/秒)，通过优化查询来减少读取次数，可以减少该计数器的值。
1 如果自由内存接近于0而且库快存或数据字典快存的命中率小于0.90，那么需要增加SHARED_POOL_SIZE的大小。
快存（共享SQL区）和数据字典快存的命中率：
select(sum(pins-reloads))/sum(pins) from v$librarycache;
select(sum(gets-getmisses))/sum(gets) from v$rowcache;
自由内存 select * from v$sgastat where name=’free memory’;
2 如果数据的缓存命中率小于0.90，那么需要加大DB_BLOCK_BUFFERS参数的值（单位：块）。
缓冲区高速缓存命中率：
select name,value from v$sysstat where name in (‘db block gets’,
‘consistent gets’,'physical reads’) ;
Hit Ratio = 1-(physical reads / ( db block gets + consistent gets))
3 如果日志缓冲区申请的值较大，则应加大LOG_BUFFER参数的值。
日志缓冲区的申请情况：
select name,value from v$sysstat where name = ‘redo log space requests’ ;
4 如果内存排序命中率小于0.95，则应加大SORT_AREA_SIZE以避免磁盘排序。
内存排序命中率：
11.
LR通过转发请求，来捕获数据包，来形成脚本
解释：1.基于浏览器的应用程序推荐使用HTML-based Script, 脚本中采用
HTML页面的形式来表示，这种方式的Script脚本容易维护，容易理解，使用该选项中的advance中的第一个选项，如果单纯的HTML方式，是不允许使用关联的。
2．不是基于浏览器的应用程序推荐使用URL-based Script，脚本中的表示采用基于URL 的方式，不是很好阅读。
解释：1.是否记录录制过程中的ThinkTime，如果记录，还可以设置最大值，一般我不记录这个值。
2．通知Vugen去重新设置每个action之间的Http context，缺省是需要的。
3．完整记录录制过程的log，
4．保存一个本地的snapshot，可以加速显示
5．把html的title放到web_reg_find函数里面
6.支持的字符集标准
7．Http header的录制，我们采用缺省即可，不需要用web_add_header去录制非标准的header信息。
对录制的content的内容进行filter，不作为resource处理的。
解释：这个就是我前面提到的关联，系统已经预先设置好了一些常见的关联rules，我们录制脚本之前，可以把系统的
12.
13.
关联：很多构架用sessionid等方法标识不同任务和数据，应用在每次运行时方式发送数据不完全相同，需要利用的机制对录制的脚本进行处理，这种机制叫做关联（服务端发送到客户端）
14.
目标场景，手工场景
15.
16.
17.
web_reg_save_param()函数主要根据需要做关联的动态数据前面和后面的固定字符串来识别、提取动态数据，所以在做关联时，需要找出动态数据的左、右边界字符串。
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
在init、end中不能使用集合点、事务等, init、end只执行一次。
31.
32.
33.
HTTP-request connect timeout、HTTP-request receive timeout、step download timeout
34.
ContentCheck的设置是为了让VuGen检测何种页面为错误页面。如果被测的Web 应用没有使用自定义的错误页面，那么这里不用作更改；如果被测的Web应用使用了自定义的错误页面，那么这里需要定义，以便让VuGen 在运行过程中检测，服务器返回的页面是否包含预定义的字符串，进而判断该页面是否为错误页
面。如果是，VuGen就停止运行，指示运行失败。
使用方法：点击在runtime settings中点击“contentcheck”，然后新建立一个符合要求的应用程序和规则，设定需要查找的文本和前缀后缀即可使用。
35.
模拟用户访问速度的带宽。
36.
可以很直观的看到，在负载下系统的运行情况以及各种资源的使用情况，可以对系统的性能瓶颈定位、性能调优等起到想要的辅助作用。
37.
在controller中，点击detailis－Refresh-script即可。
38.
线程有自己的全局数据。线程存在于进程中,因此一个进程的全局变量由所有的线程共享。由于线程共享同样的系统区域,操作系统分配给一个进程的资源对该进程的所有线程都是可用的,正如全局数据可供所有线程使用一样。在Controller中将使用驱动程序（如mdrv.exe、r3vuser.exe）运行vuser。如果按进程运行每个vuser，则对于每个vuser实例，都将反复启动同一驱动程序并将其加载到内存中。将同一驱动程序加载到内存中会占用大量的RAM（随机存储器）及其他系统资源。这就限制了可以在任一负载生成器上运行的vuser数量。如果按线程运行每个vuser，Controller为每50个vuser（默认情况下）仅启动驱动程序（如mdrv.exe）的一个实例。该驱动程序将启动几个vuser，每个vuser都按线程运行。这些线程vuser将共享父驱动进程的内存段。这就消除了多次重新加载驱动程序/进程的需要，节省了大量内存空间，从而可以在一个负载生成器上运行更多的Vuser.
39.
40.
41.
Ａ：通用的ＡＰＩ：，就是跟具体的协议无关，在任何协议的脚本里都能用的；
Ｂ：针对协议的：像lrs前缀是winsock的；lrd的是针对database;
Ｃ：自定义的：这个范围就比较广了；比如至少有Java Vuser API、lrapi、XML API。还可以添加WindowsAPI和自定义函数库。
42.
【lr_message】 int lr_message (const char *format, exp1, exp2,…expn.);中文解释：lr_message函数将信息发送到日志文件和输入窗口。在VuGen中运行时，输入文件为output.txt。
【lr_log_message】 int lr_log_message (const char *format, exp1, exp2,…expn.);中文解释：lr_log_message函数将消息发送到Vuser或代理日志文件（取决于应用程序），而不是发送到输出窗口。通过向日志文件发送错误消息或其他信息性消息，可以将该函数用于调试。
【lr_output_message】 int lr_output_message (const char *format, exp1, exp2,…expn.);中文解释：lr_output_message函数将带有脚本部分的行号的消息发送到输出窗口和日志文件。
【lr_debug_message函数组】 int lr_debug_message (unsigned int message_level, const char *format, … );中文解释：lr_debug_message函数在指定的消息级别处于活动状态时发送一条调试信息。如果指定的消息级别未出于活动状态，则不发送消息。您可以从用户界面或者使用lr_set_debug_message，将处于活动状态的消息级别设置为MSG_CLASS_BRIEF_LOG或MSG_CLASSS_EXTENDED_LOG。要确定当前级别，
请使用lr_get_debug_message。 unsigned int lr_get_debug_message ( );中文解释：lr_get_debug_message函数返回当前的日志运行时设置。该设置确定发送到输出端的信息。日志设置是使用运行时设置对话框或通过使用lr_set_debug_message函数指定的。 int lr_set_debug_message (unsigned int message_level, unsigned int on_off); 中文解释：lr_set_debug_message函数设置脚本执行的调试消息级别message_lvl。通过设置消息级别，可以确定发送哪些信息。启动设置的方法是将LR_SWITCH_ON作为on_off传递，禁用设置的方法是传递LR_SWITCH_OFF。
【lrd_stmt】：将SQL语句与光标关联
【lrd_fetch】:提取结果集中得下一条记录
43.
Oracle数据库：
同一场景
1.小用户量的情况下测试
2.大用户量情况下的测试
分析的方法：
整个系统架构分析，系统响应时间消耗，利用图表分析
查看事务响应时间，通过事务摘要图分析事务响应时间，那个消耗最大（通过小用户量和大用户量的响应时间分析，查看那个事务响应时间最高），确定哪部分功能是性能的瓶颈，分析window resource图表，查看cpu
使用下列计数器标识cpu瓶颈
Processor\ Interrupts/sec
Processor\ % Processor Time
Process(process)\ % Processor Time
System\ Processor Queue Length
通过它来确定是否硬件本身出现瓶颈，或者进一步确定应该怎么去判断性能产生瓶颈的地方！
下一步去判断进程，那个进程消耗cpu最高
下边就有很多种情况需要你自己去判断，有可能是进程调用了的函数消耗了系统资源形成上边的问题，也有可能是后台数据库出现的问题（这个就要看你的系统配置是什么样的，比如你的db服务器和应用服务器都配置在一台机器上）
性能产生瓶颈有很多地方，所以需要进一判断，是否是后台数据库的问题还有待分析，是那条语句导致的问题需要进一步分析判断。
分析原则：
• 具体问题具体分析（这是由于不同的应用系统，不同的测试目的，不同的性能关注点）
• 查找瓶颈时按以下顺序，由易到难。
服务器硬件瓶颈-〉网络瓶颈（对局域网，可以不考虑）-〉服务器操作系统瓶颈（参数配置）-〉中间件瓶颈（参数配置，数据库，web服务器等）-〉应用瓶颈（SQL语句、数据库设计、业务逻辑、算法等）
注：以上过程并不是每个分析中都需要的，要根据测试目的和要求来确定分析的深度。对一些要求低的，我们分析到应用系统在将来大的负载压力（并发用户数、数据量）下，系统的硬件瓶颈在哪儿就够了。
• 分段排除法很有效
分析的信息来源：
•1 根据场景运行过程中的错误提示信息
•2 根据测试结果收集到的监控指标数据
一．错误提示分析
分析实例：
1 •Error: Failed to connect to server “10.10.10.30:8080″: [10060] Connection
•Error: timed out Error: Server “10.10.10.30″ has shut down the connection prematurely
分析：
•A、应用服务死掉。
（小用户时：程序上的问题。程序上处理数据库的问题）
•B、应用服务没有死
（应用服务参数设置问题）
例：在许多客户端连接Weblogic应用服务器被拒绝，而在服务器端没有错误显示，则有可能是Weblogic中的server元素的 AcceptBacklog属性值设得过低。如果连接时收到connection refused消息，说明应提高该值，每次增加25％
•C、数据库的连接
(1、在应用服务的性能参数可能太小了 2、数据库启动的最大连接数（跟硬件的内存有关）)
2
分析：可能是以下原因造成
•A、应用服务参数设置太大导致服务器的瓶颈
•B、页面中图片太多
•C、在程序处理表的时候检查字段太大多
二．监控指标数据分析
1．最大并发用户数：
应用系统在当前环境（硬件环境、网络环境、软件环境（参数配置））下能承受的最大并发用户数。
在方案运行中，如果出现了大于3个用户的业务操作失败，或出现了服务器shutdown的情况，则说明在当前环境下，系统承受不了当前并发用户的负载压力，那么最大并发用户数就是前一个没有出现这种现象的并发用户数。
如果测得的最大并发用户数到达了性能要求，且各服务器资源情况良好，业务操作响应时间也达到了用户要求，那么OK。否则，再根据各服务器的资源情况和业务操作响应时间进一步分析原因所在。
2．业务操作响应时间：
• 分析方案运行情况应从平均事务响应时间图和事务性能摘要图开始。使用“事务性能摘要”图，可以确定在方案执行期间响应时间过长的事务。
• 细分事务并分析每个页面组件的性能。查看过长的事务响应时间是由哪些页面组件引起的？问题是否与网络或服务器有关？
• 如果服务器耗时过长，请使用相应的服务器图确定有问题的服务器度量并查明服务器性能下降的原因。如果网络耗时过长，请使用“网络监视器”图确定导致性能瓶颈的网络问题
3．服务器资源监控指标：
内存：
1 UNIX资源监控中指标内存页交换速率（Paging rate），如果该值偶尔走高，表明当时有线程竞争内存。如果持续很高，则内存可能是瓶颈。也可能是内存访问命中率低。
2 Windows资源监控中，如果Process\Private Bytes计数器和Process\Working Set计数器的值在长时间内持续升高，同时Memory\Available bytes计数器的值持续降低，则很可能存在内存泄漏。
内存资源成为系统性能的瓶颈的征兆:
很高的换页率(high pageout rate);
进程进入不活动状态;
交换区所有磁盘的活动次数可高;
可高的全局系统CPU利用率;
内存不够出错(out of memory errors)
处理器：
1 UNIX资源监控（Windows操作系统同理）中指标CPU占用率（CPU utilization），如果该值持续超过95%，表明瓶颈是CPU。可以考虑增加一个处理器或换一个更快的处理器。如果服务器专用于SQL Server,可接受的最大上限是80-85%
合理使用的范围在60%至70%。
2 Windows资源监控中，如果System\Processor Queue Length大于2，而处理器利用率（Processor Time）一直很低，则存在着处理器阻塞。
CPU资源成为系统性能的瓶颈的征兆:
很慢的响应时间(slow response time)
CPU空闲时间为零(zero percent idle CPU)
过高的用户占用CPU时间(high percent user CPU)
过高的系统占用CPU时间(high percent system CPU)
长时间的有很长的运行进程队列(large run queue size sustained over time)
磁盘I/O：
1 UNIX资源监控（Windows操作系统同理）中指标磁盘交换率（Disk rate），如果该参数值一直很高，表明I/O有问题。可考虑更换更快的硬盘系统。
2 Windows资源监控中，如果 Disk Time和Avg.Disk Queue Length的值很高，而Page Reads/sec页面读取操作速率很低，则可能存在磁盘瓶径。
I/O资源成为系统性能的瓶颈的征兆 :
过高的磁盘利用率(high disk utilization)
太长的磁盘等待队列(large disk queue length)
等待磁盘I/O的时间所占的百分率太高(large percentage of time waiting for disk I/O)
太高的物理I/O速率:large physical I/O rate(not sufficient in itself)
过低的缓存命中率(low buffer cache hit ratio(not sufficient in itself))
太长的运行进程队列，但CPU却空闲(large run queue with idle CPU)
4．数据库服务器：
SQL Server数据库：
1 SQLServer资源监控中指标缓存点击率（Cache Hit Ratio），该值越高越好。如果持续低于80%，应考虑增加内存。
2 如果Full Scans/sec（全表扫描/秒）计数器显示的值比1或2高，则应分析你的查询以确定是否确实需要全表扫描，以及SQL查询是否可以被优化。
3 Number of Deadlocks/sec(死锁的数量/秒)：死锁对应用程序的可伸缩性非常有害，并且会导致恶劣的用户体验。该计数器的值必须为0。
4 Lock Requests/sec(锁请求/秒)，通过优化查询来减少读取次数，可以减少该计数器的值。
Oracle数据库：
1 如果自由内存接近于0而且库快存或数据字典快存的命中率小于0.90，那么需要增加SHARED_POOL_SIZE的大小。
快存（共享SQL区）和数据字典快存的命中率：
select(sum(pins-reloads))/sum(pins) from v$librarycache;
select(sum(gets-getmisses))/sum(gets) from v$rowcache;
自由内存 select * from v$sgastat where name=’free memory’;
2 如果数据的缓存命中率小于0.90，那么需要加大DB_BLOCK_BUFFERS参数的值（单位：块）。
缓冲区高速缓存命中率：
select name,value from v$sysstat where name in (‘db block gets’,
‘consistent gets’,'physical reads’) ;
3 如果日志缓冲区申请的值较大，则应加大LOG_BUFFER参数的值。
日志缓冲区的申请情况：
select name,value from v$sysstat where name = ‘redo log space requests’ ;
4 如果内存排序命中率小于0.95，则应加大SORT_AREA_SIZE以避免磁盘排序。
内存排序命中率：
1.Loadrunner支持哪些常用协议？
Web(HTTP/HTML)
Sockets
.net 协议
web services
常用数据库协议（ODBC，ORACLE，SQLSERVER 等）
邮件(SMTP、pop3)
其它协议
2..Loadrunner包含哪几个组件？
Virtual UserGenerator： 录制测试脚本
Controller： 创建、运行、监控场景
Load Generator： 通过运行 Vuser 产生负载。
Analysis：查看和分析性能结果。
（Virtual User Generator、Controller、Analysis是loadrunner的三大组件）
3. Loadrunner的测试流程？
1）.使用VUG录制脚本：首先根据被测应用选择适当的协议。
录制脚本
增强和编辑脚本（包括插入事务点、插入集合点、脚本参数化、关联等）
回放脚本，检测脚本是否有误
2）使用controller创建场景
设置场景主要包含：选择脚本，设定执行用户数，选择测试负载机，设置脚本执行的方式，设置集合点策略，设置Run-TimeSetting。
设置服务器监控计数器。包含：内存，CPU，线程，进程，网络，磁盘等
3）运行场景
4）使用Analysis分析测试结果
查看事务的响应时间、服务器的吞吐量，执行用户人数、查看服务器监控的计数器图。
分析各个曲线图是否存在异常情况。比如：响应时间是否满足需求；系统是否支持要求的并发；吞吐量是否存在瓶颈等等；分析服务器各个性能指标是否符合需求，比如：可用内存曲线是否正常，是否存在内存泄漏；CPU利用率曲线是否平缓，是否低于90%；线程数是否正常；网络带宽是否满足流量需求；磁盘是否满足用户操作要求等等
4.server服务器的主要性能测试指标？
1)判断CPU瓶颈
1， %processor time 平均值大于95
2， processor queue length大于2(大于处理器个数+1).可以确定CPU瓶颈
3， CPU空闲时间为零(zero percent idle CPU)
4， 过高的用户占用CPU时间(%User Time)
5, 过高的系统占用CPU时间(%Priviliaged Time：长期大于90%或者95%)
备注：
%User time(processor_total)表示耗费CPU的数据库操作，如排序，执行aggregatefunctions等。如果该值很高，可考虑增加索引，尽量使用简单的表联接，水平分割大表格等方法来降低该值
如果发现processor queue length显示的队列长度超过2,而处理器的利用率却一直很低,或许更应该去解决处理器阻塞问题,这里处理器一般不是瓶颈。
2)判断内存瓶颈与内存泄漏
1，如果发生了内存泄漏,process\private bytes计数器和process\workingset 计数器的值往往会升高,同时avaiable bytes的值会降低。
2，如果Available Mbytes（剩余物理内存数）的值很小(4 MB 或更小)，则说明计算机上总的内存可能不足，或某程序没有释放内存。
3)定位磁盘瓶颈
1， % Disk Time 和Avg.DiskQueue Length 的值 (应不大于组成物理磁盘的主轴数的1.5 到2倍) 很高，而Page Reads/sec页面读取操作速率很低，则可能存在磁盘瓶径。
2，Physical Disk\ Disk Reads/sec and Disk Writes/sec 大于20 ms,则有可能磁盘瓶颈
3，Avg.Disk sec/Transfer 盘中写入数据的平均时间，单位是秒，一般来说，定义该值小于15ms最为优异，介于15-30ms之间为良好，30-60ms之间为可以接受，超过60ms则需要考虑更换硬盘或硬盘的RAID方式了
4，Disk Transfers/sec 指在此盘上读取/写入操作速率。正常值<(Disk Bytes/sec)/3，此值过大表示系统要求的IO速度已接近硬盘的最大速度，要更换更快的硬盘。
备注：如果使用 RAID 设备，% Disk Time 计数器会指示大于 100% 的值。
4)定位网络瓶颈Byte Total/sec 表示网络中接受和发送字节的速度，可以用该计数器来判断网络是否存在瓶颈（参考值：该计数器和网络带宽相除，<50%）
5)SQL Server 相关
1, SQLServer:CacheManage->Cache Hit Ratio 显示在高速缓存中找到数据的命中率。如果数值持续小于 85%， 则表示内存有问题。
2, SQLServer:Locks->LockWaits/sec 显示在当前进程完成之前强制其他进程等待的每秒锁定请求的数量。如果该值始终大于 0， 则表示事务有问题。
3, SQLServer:Databases->Transactions/sec 每秒为数据库启动的事务数
5. 简述LoadRunner的工作原理？
loadrunner会自动监控指定的URL或应用程序所发出的请求及服务器返回的响应，它做为一个第三方（Agent）监视客户端与服务器端的所有对话，然后把这些对话记录下来，生成脚本，再次运行时模拟客户端发出的请求，捕获服务器端的响应。
6一个性能测试项目，请阐述你的实施流程。
答案：
测试设计阶段：
1）了解被测系统的性能 需求 ，定义测试目标和范围；
2）了解系统的技术信息，如系统架构等；
3）确定测试方案、进度安排，并制定测试计划,场景设置方案,及需要收集的测试数据；
4）同相关人员协商讨论测试方案；
5）准备数据收集模板；不同项目的性能测试，需要收集的数据不同；针对性的制定一个模板，更符合需要；
测试环境准备：
1）技术准备；选择性能测试工具；测试方案中涉及到的技术问题；测试数据的收集方案实现；如：如何监控系统资源等；
2）搭建测试环境；
3）创建初始数据；如虚拟用户使用的账号等；
测试执行阶段：
1）录制脚本；
2）调试和增强脚本；
3）执行场景；
4）收集测试数据，并简单整理；
测试分析阶段：
1）分析测试数据；
提交测试报告 。
7常用的性能指标的名称与具体含义
· 并发：所有用户在同一时刻对系统执行操作，一般指做同一件事情或操作。
· 在线：所有用户在一段时间内对系统执行操作。
· 请求响应时间
从client端发出请求到得到响应的整个时间；
包括：client端响应时间+网络响应时间+Server端响应时间。
· 事务请求响应时间
完成相应事务所用的时间；这个是性能测试中重点关注的指标。
· TPS（Transaction Per Second）
每秒钟系统能够处理的交易或事务的数量。它是衡量系统处理能力的重要指标。TPS是LoadRunner中重要的性能参数指标。
· 点击率（Hit Per Second）
每秒发送的HTTP请求的数量；点击率越大对Server的压力越大
· 资源利用率
对不同资源的使用程度，如CPU，I/O,内存
1533
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
