http协议跑脚本的时候把浏览器静态图片资源去掉，直接测对服务器的压力

1.工具啥的

1）LR,HP PC

2）监控工具

1数据库：---sybase--proDBA,oracle---awr, Enterprise Manager 11g ;

2服务器：nmom

3 JVM的监控与分析:visualvm

VisualVM 是java虚拟机自带监控工具，使用比较简单方便，可以监控java虚拟机的堆内存、垃圾回收、进程线程、CPU使用情况等，而且在监控过程中，收集的数据量较少，对于压力机及服务器的资源占用较少，可以进行实时监控，但是正是因为搜集数据较少，因此有些性能问题很难通过它来进行定位。 

使用Jprofile定位瓶颈比较简单，因为工具基本就可以把相应的数据抓取出来，而使用VisualVM定位问题就要麻烦一些。因为收集出来的数据都需要自己手工或者工具再次进行分析。 

以定位系统内存泄露为例，首先要生成被监控程序的heapdump，之后建议使用smzy_HeapAnalyzer(Java内存使用分析 HeapAnalyzer.rar)来进行分析，请注意，使用该工具是同样需要调用jvm，需要赋予JVM足够的内存，至少要比被分析的heapdump文件要大。一般将启动程序ha39.jar部署到服务器上，heapdump分析非常占用资源，尽量使用服务器来处理。 

常用启动命令格式如下：java -Xmx4000m -jar ha39.jar 

对 heapdump进行分析之后，就可以查询并定位当前系统堆内存中存在的最多对象是什么，哪些东西无法进行垃圾回收。 

应用服务器操作系统：SuseLinux10/ linux RedHad AS5, AIX6.1,unix等

应用服务器监控工具：nmom

中间件：websphere7.0.0.13；weblogic10.3

数据库：sybase15.0.3；数据库1：Sybase IQ/数据库2：Sybase ASE15.70

数据库连接工具：DbVisualizer 7.1.2 或者Aqua Data Studio 6.5.0/ ADS（Aqua Data Studio.7.0）

数据库操作系统：AIX6.1

数据库监控工具：proDBA

测试压力机：直接连到Performance Center 11进行测试

测试工具：loadrunner 11及Performance Center 11

缺陷管理工具：butterfly,QC11.00

网络：总行千兆局域网络

2.还会有项目流程这些

性能需求、业务流程熟悉，环境准备搭建、测试数据准备、脚本编写调试、跑压力测试---基准测试，单场景测试，混合场景测试，稳定性疲劳测试

3.集合点是哪个函数

web_reg_save_param   基于包含在 HTML 页内的动态信息创建参数（不使用嵌入边界）。

4场景里怎么加集合点

1）脚本里设置集合点lr_rendezours(“test”);

2）Controller启动，进行集合点策略配置---全部用户，多少运行用户，多少用户数设置

5跑稳定的时候空间不够了怎么清

一般稳定性8小时，提前清理好空间、日志啥的、跑LR脚本的日志关闭；

另外求助环境管理部门协助解决

6怎么看目录剩余空间

Df命令是linux系统以磁盘分区为单位查看文件系统，可以加上参数查看磁盘剩余空间信息，命令格式：df -hl显示格式为：

文件系统 容量 已用 可用 已用% 挂载点

Filesystem Size Used Avail Use% Mounted on/

dev/hda2 45G 19G 24G 44% 

//dev/hda1 494M 19M 450M 4% 

/boot/dev/hda6 4.9G 2.2G 2.5G 47% /home/dev/hda5 9.7G 2.9G 6.4G 31% /optnone 1009M 0 1009M 0% /dev/shm/dev/hda3 9.7G 7.2G 2.1G 78% /usr/local/dev/hdb2 75G 75G 0 100% //dev/hdb2 75G 75G 0 100% /以上面的输出为例，表示的意思为：HD硬盘接口的第二个硬盘（b），第二个分区（2），容量是75G，用了75G，可用是0，因此利用率是100%， 被挂载到根分区目录上（/）。

下面是相关命令的解释：

df -hl 查看磁盘剩余空间

df -h 查看每个根路径的分区大小

du -sh [目录名] 返回该目录的大小

du -sm [文件夹] 返回该文件夹总M数

更多功能可以输入一下命令查看：df –help

du –help

查看linux文件目录的大小和文件夹包含的文件数 统计总数大小 du -sh xmldb/ du -sm * | sort -n //统计当前目录大小 并安大小 排序 du -sk * | sort -n du -sk * | grep guojf //看一个人的大小 du -m | cut -d "/" -f 2 //看第二个/ 字符前的文字 查看此文件夹有多少文件 /*/*/* 有多少文件 du xmldb/ du xmldb/*/*/* |wc -l 40752 解释： wc [-lmw] 参数说明： -l :多少行 -m:多少字符 -w:多少字

7用lr的时候遇到什么印象深刻的问题

1）tuxedo library libwsc.dll was not found in search path-----tuxedo库文件找不到----

1开发环境步骤1>安装Tuxedo9.1 2>安装C++Builder 2009 3>设置Path 添加;%TUXDIR%\\bin【否则会报“找不到WTUXWS32.DLL…”错误】——

2tuxedo调用接口：UBPS_installer.v1.5.0.5_build.071108.exe；安装后会在C:\\sysnet\\Chinalife\\bin目录下生成wtuxws32.dll；安装完后需要重启计算机

2）合理设计脚本，节省造数时间 

（1）001上送投保单->033转入->034转出 

——每个交易需要按顺序执行 

（2）每个交易构造10000个保单号耗时长： 

——001上送投保单:10用户迭代跑1000次耗时将近4h

——033转入: 10用户迭代跑1000次耗时将近4h

（3）脚本设计 

——关联：把“001上送投保单->033转入”两个交易的脚本合并 

——参数化

3）万能系统总计发现两个问题： 

1、遇到问题：新单生效耗时部分sql运行时间长 

   解决方式：增加查询表索引。 

第一个增加索引

create index I1PLCBINDINFOBINDPAPERNO on T1PLCBINDINFO (BINDPAPERNO)

2、遇到问题：保费划转8版功能，在万能系统压力增大时，运行效率较低，sql硬代码解析耗时严重。 

   解决方式：修改保费划转代码，优化sql查询逻辑，使用捆绑变量实现。 

通过优化，36用户并发时响应时间由0.53s->0.19s

具体优化内容：

查询t1plcbase、tufundplc、tufundacct表存在硬代码

具体sql： select 所有字段  from 上述表名  where plcno =指定保单号

第二个优化使用捆绑变量；sql还是一样的

4）1单基本信息查询服务的性能测试。测试过程中进行100个保单并发查询时，查询到2分钟时，查询服务收不到响应。压力机上报timeout的错误。

经过查看日志以及查询weblogic的控制台信息，发现压力机流量停掉后，后台进程一直不释放。

2当100 用户并发时，发现很多用户查询都失败了，系统收到timeout的错误。 经排查日志中有javax.jms.InvalidDestinationException的异常。这个经开发定位是“大量 

调用了之后，查询结果返回队列找不到回来的路径”

2. 解决问题1后，进行100并发时，所以事务都pass。经统计平均响应时间为32s，TPS为3

通过排查后台日志，发现查询时间大部分都是0.1s左右就完成了，大部分时间都消耗在队列中。 这个还在定位中。

3. 开发修改连接池，把weblogic配置给数据源的空间全释放了，让服务控制连接池。再次进行100并发测试，再次发现查询失败的现象。经排查连接池释放的很慢，连接被占满，有一大堆close_wait 端口等待关闭。

-----队列系统，和权限数据库；队列上把异步改成了同步，因为本来就是同步的；权限数据库就是单纯的换了个地址，以前那个太慢了

5）农行风险管理报表查询导出的性能测试：

脚本报查询检查点找不到以及查询处关联报错

在关联前加web_set_max_html_param_len("3999999999");函数50并发脚本报错

6)薪酬管理优化升级系统

（1）员工基本信息维护---该交易加集合点400并发时，新增员工信息响应时间大于5秒不符合需求规定，并且新增员工信息成功后，在界面无法查询到相关信息;另外,发现数据库有死锁----新增交易加了索引，并且把表锁改为行锁

（2）该交易50并发时，薪酬批次状态管理历史归档交易loadrunner报找不到检查点，后台服务报错日志为“--- The error occurred in com/abchina/acs2/history/wagehistory/dao/WageHistoryDao.xml.  

--- The error occurred while applying a parameter map.  

--- Check the com.abchina.acs2.history.wagehistory.dao.WageHistoryDao.batchIntoHistory-InlineParameterMap.  

--- Check the statement (update failed).  

--- Cause: com.sybase.jdbc3.jdbc.SybSQLException: ASE has run out of LOCKS. Re-run your command when there are fewer active users, or contact a user with System Administrator (SA) role to reconfigure ASE with more LOCKS”---将数据库锁从1万加到50万

（3）

10并发该交易可以顺利通过，30并发lr监控到相应时间为28秒，抓取最长sql为400多秒并且was后台报大量错误

8数据库中间件怎么监控的监控哪些内容

Oracle----服务器资源利用率；awr报告---；em: SQL响应时间; ADDM

自动数据库性能监视器; ADDM是构建在Oracle数据库内部的自我诊断软件，ADDM检查并分析自动工作量仓库（AWR）捕获到的数据，确定Oracle数据库可能存在的性能问题，然后它定位性能问题的根本原因，为纠正这些性能问题提供建议，并量化预计的性能收益，ADDM也可以识别不需要行动的区域;

1.CPU的瓶颈 

2.内存结构上的瓶颈 (SGA,PGA是否已经合理地设置 ?)

3.I/O 是否存在性能瓶颈? (I/O子系统是否工作正常 ?)

4.高负载的SQL语句 (是否存在消耗过量系统资源的SQL ?)        

5.高负荷的PLSQL执行和编译,同时是否存在高负荷的JAVA使用?

6.连接池的管理,  过量的解析,  应用程序层的锁竞争。 

7.数据库配置的问题，如日志大小是否合理，归档是否有问题等。 

8.并发的问题: 是否存在"缓冲区忙"的问题?

中间件——WAS,weblogic控制台看性能表现：活动队列，线程阻塞——不释放、jdbc连接池、jvm堆大小------求助环境管理部解决

weblogic一般来说监控jvm的使用、执行线程队列情况、和连接池的变化情况，还有一个很重要的检查weblogic的console日志这里经常能反映一些很重要到情况。

下面列举部分用来管理WebLogic的监视页面来简要说明管理控制台所提供的监视功能。

1.

   服务器->监视->常规，该页面显示了服务器的当前状态。高级选项里还显示了WebLogic 版本，JDK的提供商，版本，操作系统的版本等信息。最后从这个页面，还可以访问JNDI 树、监视活动队列、监视连接以及监视活动套接口。

2.

   服务器->监视->常规->监视所有活动队列，执行队列的配置对WebLogic 性能是很重要的，根据经验值，一颗CPU可以配置25-30之间的执行线程。从该页面可以查看到已经分配给队列的执行线程数，当前空闲的线程数，最长等待请求放入队列中的时间，队列中的等待请求数，此队列已处理的请求数等重要信息，这些信息可以作为判断是否需要对执行线程调整的参考。

   服务器->监视->性能，从该页面中可以了解WebLogic 服务器性能的基本情况，包括空闲线程数，等待处理的请求数，JVM的内存堆使用状态等。

   部署->应用程序->EAR模块->监视，当应用程序部署运行后，可以监视单一组件，如EJB,Servlet等。如上图所示，该页面提供了发布的应用程序中EJB的统计信息，可以有效了解EJB处理请求的效率。

   服务->JDBC->连接缓冲池->监视，在控制台中可以监视资源的运行的状态，如JDBC等。该页面提供了JDBC连接缓冲池的统计信息，包括连接缓冲池可包含的最大数据库连接数，当前使用的物理数据库连接数，当前使用的物理数据库连接数等信息。

就这样的东西看你怎么介绍项目了他们可能根据你说的想起来啥就问下载本文