总结——LR丰台项目总结

阅读量：5775 次

发布时间：2019-06-18

本文共 14221 字，大约阅读时间需要 47 分钟。

1，Weblogic 配置文件：

配置用户名和密码，和内存大小。

Weblogic 设置：

粘滞线程最长时间：3600

JTA超时时间：3000秒。

2，清除服务器的缓存：

linux上直接执行这个指令：echo 1 >/proc/sys/vm/drop_caches

3，名称概念：

吞吐量：指在一次性能测试过程中网络上传输的数据量的总和。

吞吐量：是指系统在单位时间内网络上传输的数据量。

吞吐率：给吞吐量加上单位之后就是吞吐率。单位时间内网络上传输的数据量，也可以指单位时间内处理客户端请求数量。

TPS:每秒钟系统能够处理事务或交易的数量，它是衡量系统处理能力的重要指标。

点击率（hit per second）：每秒钟用户向web服务器提交的http请求数。

点击率更能体现用户端对服务器的压力。Tps更能体现服务器对客户端请求的处理能力。

4，

一般来说，/etc/oraInst.loc文件里会记录oracle的路径，如  [oracle@ruby ~]$ cat /etc/oraInst.loc  inventory_loc=/u01/app/oraInventory  inst_group=oinstall 然后/u01/app/oraInventory/ContentsXML/inventory.xml里记录了你安装的所有oracle产品的目录信息  oracle用户家目录中的.bash_profile中在安oracle时会设置环境变量的，里面有$ORACLE_BASE和$ORACLE_HOME  [oracle@ruby ~]$ echo $ORACLE_HOME 在$ORACLE_HOME/OPatch里，执行$./opatch lsinventory能看到oracle版本、家目录等信息

5，压测：

随着用户数的增加，点击率和响应时间应逐渐增加，直到用户数增到最大。

6,判断内存泄露:

在weblogic 控制台中,手动"垃圾收集"的时候，总是不能全部回收，一次比一次占用的内存多。

7,内存分配

服务器分配内存10g , 但是给weblogic 分配了8g , 所以在服务器长时间运行之后,free 查看的内存剩余只有几百兆. 因为分配给weblogic 的8g内存会分配给weblogic，所以free查看时，以为这部分内存全部被占用。但是通过jprofile查看时，是准确的查看weblogic被分配的内存的占用情况，可以看出这部分内存在不断的占用和释放的过程。

服务器自身再占用15%左右的内存.

压测时判断内存是否泄漏看6 . 或者通过jprofile查看，内存的占用情况。

与此同时,用free 查看内存情况，free 是虚拟机的整体内存情况。

所以内存是不是泄露，需要看jprofile中，每次压测后内存是否释放完成。

然后监视这里，就能确定内存是否泄露。

8，jdbc连接池使用情况

9，场景设计-手工场景方案(Schedule)设计

by:授客 QQ：1033553122

A. 定义方案schedule

在 Scenario Schedule面板中,选择一个方案schedule,或通过点击New Schedule定义一个新的方案

定义schedule:

a、新建schedule：点击新建按钮(可选)

b、重命名schedule:在Schedule Name输入新的名字并点击Save New Name(可选).

c、选择schedule类型,Schedule by: Scenario 或 Group.

d、选择运行模式Run mode: Real-world 或Basic

说明:

1．对所有schedule默认的运行模式都是Real-word.你可以改变缺省模式为Basic。Tools > Options > Execution tab

2. Schedule by Scenario和Group的区别

Real-world Schedule和Basic schedule的区别：根据官方文档，这两种模式下，场景中的每个虚拟用户组(可看成是每个脚本)都会按照它们自己的Run-Time settings中的设置运行。区别在于可模拟的操作不一样：

Schedule by:Scenario

Basic Schedule：可以定义每次运行多少用户，场景持续运行多久

Real-world Schedule:同Basic schedule，除此之外，还可以设置每次停止多少个用户。

Schedule by:Group(该设置在百分比模式下不可见)

Basic schedule：可以定义什么时候开始运行虚拟用户组(Group和Scenario的主要区别)，每次运行多少个虚拟用户，场景持续运行多久

Real-world Schedule:同Basic Schedule，除此之外，还可以设置每次停止多少个虚拟用户。

双击Group Schedule下的Start Group Action，打开Start Group策略，设置脚本在手工场景下的Group模式中如何开始运行

B. 为schedule定义action(Global schedule)

Actions表格展示了默认的与步骤2选择的shedule对应的actions。

Schedule Actions.

一个场景schedule包含了一系列actions，指导场景什么时候运行Vuser group，怎么初始化虚拟用户，合适开始和停止虚拟用户，及运行一个action要花的时间。

注意:

脚本中带集合点会妨碍场景方案的运行。如果有包含集合点，场景可能不会按照你设定的方案运行。

说明：

1) Start Group

定义何时开始运行Vuser Group

1、Start immediately after the scenario begins(缺省)

LoadRunner在场景一运行就开始运行Vuser Group

2、Start <00:00:00> (HH:MM:SS) after the scenario begins

场景运行后，LoadRunner等待指定的时间后开始运行Vuser group.

3、Start when group finishes

指定Vuser group运行完成后，LoadRunner马上开始运行该Vuser group.

注意:Start Group仅在group schedule类型中可用，而且总是作为第一个action出现.

2) Initialize

指导LoadRunner准备Vusers，以便于他们处于准备运行状态.

1、Initialize all Vusers simultaneously

在LoadRunner在运行vuser前初始化所有Vusers.

注意：选择该设置可能会导致运行出错：error-27796 failed to connect to server

2、Initialize XX Vusers every <00:00:00> (HH:MM:SS)

LoadRunner在运行vuser前，根据指定的时间间隔，逐渐初始指定数量的Vuser,

3、Initialize each Vuser just before it runs(Default)

LoadRunner在运行它们前初始化每一个Vuser

注意：

当Wait for all groups to initialize选项被选中时，必须等所有的Vuser group完成对虚拟用户的初始化后才运行

该选项对于group scenario不可用

3) Start Vusers

指示loadRunner开始运行Vusers。

1、Start XX Vusers: Simultaneously(Default)

指定LoadRunner运行场景的虚拟用户总数

2、Start XX Vusers: YY Vusers every <00:00:00> (HH:MM:SS)

LoadRunner按指定的时间间隔，逐步运行指定数量XX个Vusers，也就是说LoadRunner运行指定数量的一组Vusers,并且等待指定时间后运行指定下一组Vuser.

3、点击Previous 或Next可切换其它要编辑的action.

注意:

1.当且仅当Vuser处于Ready状态时，LoadRunner才开始运行Vuser.

2.Basic运行模式下默认运行所有用户

4) Duration

持续时间

Real-world schedule

Basic schedule

1、Run until completion

按Controller中Run-time settings -> logic中的迭代次数进行迭代，迭代完成则停止运行。

2、Run for x days and xx:xx:xx

忽略Run-time settings -> logic中设置的迭代次数，重复迭代运行脚本的action，直到时间结束为止，也就是说，此处设置的持续时间的优先级高，

也就是说：

1、即使你指定了迭代次数，但是运行时间没有结束之前，还是会一直迭代，所以实际迭代次数可能大于你设置的迭代次数；

2、还有一种情况是，迭代次数还没完，但是运行时间已经到了，此时会将当前执行的Action执行完，停止迭代，此种情况下实际迭代次数小于你设置的迭代次数。

3、Run indefinitely

无限运行

C. 从Actions表格中添加一个action到schedule

步骤1：打开添加Action对话框

方法1、在指定action后插入一个action，选择这个action并点击Add Action After

方法2、在最后一个action后添加一个action，在Action表格中双击最后一行

步骤2：在Add Action对话框中，定义新的action

注意：这里的Start Vuser数量的设置，会改变上方的组或脚本的虚拟用户数量Quatity

步骤3：点击Apply.

9，Linux 命令：

1，pwd 查看路径。

2，mkdir nmon 创建文件夹。

mkdir -p /adf/nmon ,如果找不到父级目录，先创建个父级目录，再创建文件夹。

3， chmod 751 file 。给file的属主分配读、写、执行(7)的权限，给file的所在组分配读、执行(5)的权限，给其他用户分配执行(1)的权限。

Top 指令：

Linux查看硬件配置：

修改ip地址：

在终端中输入：vi /etc/sysconfig/network-scripts/ifcfg-eth0

回车后，

开始编辑，填写ip地址、子网掩码、网关、DNS等。其中“红框内的信息”是必须得有的。

编辑完成后，保存退出

重启网络服务

service network restart或/etc/init.d/network restart

然后ping网关，ping外网进行测试。都能ping通表示网络正常

（process）和（thread）

1.计算机的核心是CPU，它承担了所有的计算任务。它就像一座工厂，时刻在运行。

2.假定工厂的电力有限，一次只能供给一个车间使用。也就是说，一个车间开工的时候，其他车间都必须停工。背后的含义就是，单个CPU一次只能运行一个任务。

3.进程就好比工厂的车间，它代表CPU所能处理的单个任务。任一时刻，CPU总是运行一个进程，其他进程处于非运行状态。

4.一个车间里，可以有很多工人。他们协同完成一个任务。

5.线程就好比车间里的工人。一个进程可以包括多个线程。

6.车间的空间是工人们共享的，比如许多房间是每个工人都可以进出的。这象征一个进程的内存空间是共享的，每个线程都可以使用这些共享内存。

7.可是，每间房间的大小不同，有些房间最多只能容纳一个人，比如厕所。里面有人的时候，其他人就不能进去了。这代表一个线程使用某些共享内存时，其他线程必须等它结束，才能使用这一块内存。

8.一个防止他人进入的简单方法，就是门口加一把锁。先到的人锁上门，后到的人看到上锁，就在门口排队，等锁打开再进去。这就叫（Mutual exclusion，缩写 Mutex），防止多个线程同时读写某一块内存区域。

9.还有些房间，可以同时容纳n个人，比如厨房。也就是说，如果人数大于n，多出来的人只能在外面等着。这好比某些内存区域，只能供给固定数目的线程使用。

10.这时的解决方法，就是在门口挂n把钥匙。进去的人就取一把钥匙，出来时再把钥匙挂回原处。后到的人发现钥匙架空了，就知道必须在门口排队等着了。这种做法叫做（Semaphore），用来保证多个线程不会互相冲突。

不难看出，mutex是semaphore的一种特殊情况（n=1时）。也就是说，完全可以用后者替代前者。但是，因为mutex较为简单，且效率高，所以在必须保证资源独占的情况下，还是采用这种设计。

11.操作系统的设计，因此可以归结为三点：

（1）以多进程形式，允许多个任务同时运行；

（2）以多线程形式，允许单个任务分成不同的部分运行；

（3）提供协调机制，一方面防止进程之间和线程之间产生冲突，另一方面允许进程之间和线程之间共享资源。

磁盘

Io -- Iostat

Vmstat

linux 查cpu、内存、硬盘：

一、linux CPU大小

1. [root@idc ~]# cat /proc/cpuinfo |grep "model name" && cat /proc/cpuinfo |grep "physical id"

2. model name: Intel(R) Xeon(TM) CPU 2.80GHz

3. model name: Intel(R) Xeon(TM) CPU 2.80GHz

4. model name: Intel(R) Xeon(TM) CPU 2.80GHz

5. model name: Intel(R) Xeon(TM) CPU 2.80GHz

6. physical id : 0

7. physical id : 0

8. physical id : 3

9. physical id : 3

10. [root@idc ~]#

其实应该通过Physical Processor ID来区分单核和双核。而Physical Processor ID可以从cpuinfo或者dmesg中找到. flags 如果有 ht 说明支持超线程技术判断物理CPU的个数可以查看physical id 的值，相同则为同一个物理CPU

可以看到上面，这台机器有两个双核的CPU，ID分别是0和3，大小是2.8G。

二、内存大小

1. [root@xbidc ~]# cat /proc/meminfo |grep MemTotal

2. MemTotal: 1034612 kB

3. [root@xbidc ~]#

三、硬盘大小

1. [root@xbidc ~]# fdisk -l |grep Disk

2. Disk /dev/sda: 300.0 GB, 300000000000 bytes

3. [root@xbidc ~]#

四、更多查看linux硬件信息的方法

1. uname -a # 查看内核/操作系统/CPU信息的linux系统信息命令

2. head -n 1 /etc/issue # 查看操作系统版本，是数字1不是字母L

3. cat /proc/cpuinfo # 查看CPU信息的linux系统信息命令

4. hostname # 查看计算机名的linux系统信息命令

5. lspci -tv # 列出所有PCI设备

6. lsusb -tv # 列出所有USB设备的linux系统信息命令

7. lsmod # 列出加载的内核模块

8. env # 查看环境变量资源

9. free -m # 查看内存使用量和交换区使用量

10. df -h # 查看各分区使用情况

11. du -sh # 查看指定目录的大小

12. grep MemTotal /proc/meminfo # 查看内存总量

13. grep MemFree /proc/meminfo # 查看空闲内存量

14. uptime # 查看系统运行时间、用户数、负载

15. cat /proc/loadavg # 查看系统负载磁盘和分区

16. mount | column -t # 查看挂接的分区状态

17. fdisk -l # 查看所有分区

18. swapon -s # 查看所有交换分区

19. hdparm -i /dev/hda # 查看磁盘参数(仅适用于IDE设备)

20. dmesg | grep IDE # 查看启动时IDE设备检测状况网络

21. ifconfig # 查看所有网络接口的属性

22. iptables -L # 查看防火墙设置

23. route -n # 查看路由表

24. netstat -lntp # 查看所有监听端口

25. netstat -antp # 查看所有已经建立的连接

26. netstat -s # 查看网络统计信息进程

27. ps -ef # 查看所有进程

28. top # 实时显示进程状态用户

29. w # 查看活动用户

30. id # 查看指定用户信息

31. last # 查看用户登录日志

32. cut -d: -f1 /etc/passwd # 查看系统所有用户

33. cut -d: -f1 /etc/group # 查看系统所有组

34. crontab -l # 查看当前用户的计划任务服务

35. chkconfig –list # 列出所有系统服务

36. chkconfig –list | grep on # 列出所有启动的系统服务程序

37. rpm -qa # 查看所有安装的软件包

38. cat /proc/cpuinfo ：查看CPU相关参数的linux系统命令

39. cat /proc/partitions ：查看linux硬盘和分区信息的系统信息命令

40. cat /proc/meminfo ：查看linux系统内存信息的linux系统命令

41. cat /proc/version ：查看版本，类似uname -r

42. cat /proc/ioports ：查看设备io端口

43. cat /proc/interrupts ：查看中断

44. cat /proc/pci ：查看pci设备的信息

45. cat /proc/swaps ：查看所有swap分区的信息

linux 怎样查看内存被哪个进程占用

ps aux

7，LR编写程序：

1，lr中写一段循环操作。：

int i;

char str[100]; //定义一个数组用来保存int类型转换后的值

for(i=0;i<=9;i++){

itoa(i,str,10);

lr_save_string(str,"ID");

lr_output_message("==str:=%s==ID:=%s====",str,lr_eval_string("{ID}"));

}

2,web_concurrent_start(null),web_concurrent_end(null)两个函数

以URL-based 方式录制脚本时，出现以下web_concurrent_start(null),web_concurrent_end(null)两个函数，查了一下：

URL-based 方式将每条客户端发出的请求录制成一条语句，对来说，在该模式下，一条语句只建立一个到服务器的连接，LoadRunner提供了web_concurrent_start和web_concurrent_end函数模拟HTML-based的方式，

将多个请求同时发送，不加的话这些URL是排除请求

将web_concurrent_start和web_concurrent_end中间的内容一起发，我都把他当成{}，内容放里面就行，表示这里面的东西是在一个并发组里

--------------------------------------------------------------

很多地方都没有把这个东西解释清楚。其实比较容易理解的。就是并发组这个概念把人说晕了。

简单的说：

这两个函数是在URL中标记一个页面请求的，注意：这里我说的是页面（page），并不是请求。

在LR请求一个页面里，由于使用URL的方式录制，会把一个页面中的元素分成几个函数做处理。所以，LR中实现了web_concurrent_start和web_concurrent_end。实现的作用是：

从web_concurrent_start开始标记，当脚本运行到web_concurrent_start时，后续的脚本都不会立即被执行，直到web_concurrent_end出现。才把这中间的所有的脚本一起执行。
所谓并发组也是指把这一组函数一起执行起来。

如果你用 lr_start_transaction和 lr_end_transaction来替换，脚本完全可以跑通。中间的脚本是从上到下执行的，而不是一起执行的。

的没有作用。

语法：

　int web_concurrent_start ( [char * ConcurrentGroupName,] NULL );

参数：

　ConcurrentGroupName：可选的，并发组的标识符。

NULL：参数列表结束的标记符。

返回值

　整型。返回LR_PASS (0)表示成功，返回LR_FAIL (1)表示失败。

说明

　web_concurrent_start函数是并发组开始的标记。组中所有的函数是并发执行的。并发组的结束web_concurrent_end 函数。在并发组中，可以包含的函数有：web_url、web_submit_data、web_custom_request、web_create_html_param、web_create_html_param_ex、web_reg_save_param、web_add_header。

在并发组中的函数不是立即执行的。在并发组开始时，所有的函数首先被记录下来，当并发组结束时，所有的函数并发执行。

所有的Web 用户，HTTP模式下的WAP用户持本函数。运行在Wireless Session Protocol（WSP）回放模式下的WAP虚拟用户，不支持本函数。

web_concurrent_start

　语法：

　int web_concurrent_end ( reserved );

参数：

　reserved：保留的供扩展的字段。

返回值

　整型。返回LR_PASS (0)表示成功，返回LR_FAIL (1)表示失败。

说明

　web_concurrent_end，并发组结束的标记。脚本执行时，碰到 web_concurrent_end函数时，开始并发执行所有记录的函数。

在并发组中的函数不是立即执行的。在并发组开始时，所有的函数首先被记录下来，当并发组结束时，所有的函数并发执行。

可以并发执行的函数的个数是有限制的，使用运行时设置-Netword标签页的Concurrent Connection来设置。

LR参数化：

一个用户只能送审一条数据，其他用户也送审不了该数据了，这时需要两个参数都是unique 且是once的。或者是每次迭代更新一次参数，每次调用更新参数。

1）并发时，50并发用户，每个用户，每次迭代或是每次取参都是唯一的。需要按照下面这样设置：

例如下面这种设置：

打印结果如下：

第一个用户的log 是：67，68，69，70。。。。

第二个用户的log是：84，85，86，87。。。。。

这是LR自动分配的，每个用户都是连续取值的。

2）50用户并发，每个用户都是从第一个参数取值，按照每次迭代或是每次取参更新，需要按照下面设置：

3）场景运行时，如果需要看参数的log ，需要设置log的开关，如图。

LR参数池策略总结：

下侧select next row(+when out of values)\右侧update value on	sequential	random	unique
each iteration	顺序取值，下一次迭代接着上次继续取值，第一次迭代所有该参数取第一个值，下一次迭代所有该参数取第2个值，以此类推（参数列表用完，可以继续循环重复使用参数）。	随机取值，下一次迭代继续随机取值，第一次迭代所有该参数取第一个随机值，下一次迭代所有该参数取另一个随机值，以此类推（参数列表用完，可以继续重复使用参数）。
each occurrence	顺序取值，下一次函数接着上次继续取值，第一个函数所有该参数取第一个值，下一个函数所有该参数取第2个值，以此类推（参数列表用完，可以继续循环重复使用参数）如：每一个web_url是一个函数。	随机取值，下一次函数接着上次继续随机取值，第一个函数所有该参数取第一个随机值，下一个函数所有该参数取另一随机值，以此类推（参数列表用完，可以继续重复使用参数）如：每一个web_url是一个函数。
once	n次出现、或者n次迭代都是取参数文件当中的第一个值。	n次出现、或者n次迭代都是取参数文件当中的第一个随机值。	n次出现、或者n次迭代都是取参数文件当中的第一个值。与sequential+once一样？
each iteration+abort vuser			顺序取值，下一次迭代接着上次继续取值，第一次迭代所有该参数取第一个值，下一次迭代所有该参数取第2个值，以此类推，如果迭代次数多于参数列表个数，会报No more unique values for this parameter in table 'keyword.dat'错
each iteratione+continue in a cyclic manner			顺序取值，下一次迭代接着上次继续取值，第一次迭代所有该参数取第一个值，下一次迭代所有该参数取第2个值，以此类推（参数列表用完，可以继续循环重复使用参数）。
each iteratione+continue with last value			顺序取值，下一次迭代接着上次继续取值，第一次迭代所有该参数取第一个值，下一次迭代所有该参数取第2个值，以此类推，如果迭代次数多于参数列表个数，会报No more unique values for this parameter in table 'keyword.dat'错
each occurrence+abort vuser
each occurrence+continue in a cyclic manner			顺序取值，下一次函数接着上次继续取值，第一次函数所有该参数取第一个值，下一次函数所有该参数取第2个值，以此类推（参数列表用完，可以继续循环重复使用参数）。
each occurrence+continue with last value			顺序取值，下一次函数接着上次继续取值，第一次函数所有该参数取第一个值，下一次函数所有该参数取第2个值，以此类推，如果使用该参数的函数个数多于参数列表个数，会报No more unique values for this parameter in table 'keyword.dat'错

LR场景运行时日志路径：

在tool 里生成场景的时候，这里有个路径，就是存放结果的日志路径。

C:\Users\Administrator\Desktop\zhongshen单条\res\log 下面的log里，就是日志文件。

创建关联：

Ordinal：说明第几次出现的左边界子串的匹配项才是需要的内容。该属性可有可无，缺省值是1。如为All，则将所有找到的内容储存起来。

web_reg_save_param_ex(

"ParamName=CorrelationParameter_1",

"LB=\"",

"RB=\"",

"Ordinal=9",

SEARCH_FILTERS,

"Scope=Body",

"RequestUrl=*/toLogin*",

LAST);

转义字符总结

在做手动关联时，取边界值的时候，会经常用到转义字符，现将转义字符整理如下：

\b 退格

\f 换页

\n 换行

\r 回车

\t 水平制表

\v 垂直制表

\\ 反斜杠

\? 问号字符

\' 单引号字符

\" 双引号字符

\0 空字符

场景运行一次，设置

设置场景时，选择这一项，场景运行一次后，直接结束。

LR 场景设置：

指定处理事务个数，等等

运行时设置项：

运行前设置脚本的运行策略保证整个场景中的所有用户的运行方式正确。注意Controller中Run-Time Setting独立存放在场景.lrs文件中，并不会影响脚本在VuGen中运行的设置

a) Think Time

在VuGen中，Think Time默认为忽略，但是场景中，该选项会自动按照脚本录制的lr_think_time()函数进行运行，Think Time可以模拟真实用户的操作等待，这个值必须适当，可以考虑取一个熟练用户的操作速度和一个新用户的操作速度的平均值来设置合理的Think Time值。

b) 场景中MMDRV.EXE负载的生成方式

Load Generators会调用MMDRV.EXE来生成负载，而负载的生成分为进程方式和线程方式，使用进程模式模拟负载的资源开销相对较大，每个虚拟用户会使用一个单独的mmdrv.exe来完成负载的实现，这样做用户之间会相互独立，互不影响。

而如果使用线程方式，那么所有用户都是在一个mmdrv.exe上模拟，用户行为使用线程方式，模拟消耗资源较小。

一般来说，使用线程可以在固定的硬件平台上产生更多的负载模拟，但使用线程也会存在不稳定的情况，导致用户脚本执错误。

默认都是线程方式。

c) 系统日志设置

在场景中系统日志会从Always send message变为Send message only when an error occurs,不出现错误就不记录日志，这样可以减少负载时记录日志的资源开销，从而提高模拟效率，当需要进行错误跟踪时，再将其打开。

d) 关闭自动化事务

在脚本中都会对关键的操作添加事务从而获得响应时间，一般会默认设置自动化事务(对每个Action)，导致每次都会多几个无关紧要的事务统计，为了避免多余的数据影响，建议关闭自动化事务选项。

e) 宽带模拟

宽带会直接影响到事务的响应时间，而真实环境下，每个用户的宽带也是有限的，这里需要为用户设置一个合理的宽带来得到真实用户访问的响应时间

通常情况下一个客户端在访问一个Web网站时的平均连接速度在30-50KB/s左右，这里可以选择512Kbps(DSL),为场景中的每个用户分配512Kb的带宽。为了避免出现模拟用户过多，导致load Generator出现带宽瓶颈的情况，需要在设置前进行计算，如果设置每个用户512Kb的带宽，那么在100Mb总带宽下，最多模拟个195用户(100*1000 / 512 = 195)。