1 脚本是优化的
1.1对于BS结构的脚本录制 尽量将一些图片请求 或者重复请求 或者是 动态刷新页面的请求全部干掉
1.2 函数使用 ：正式跑场景的时候将调试函数屏蔽 lr_out_message lr_log_message lr_error_message 等 关联函数的参数选择 ---- to_date to_char
2.客户端：压力机本身优化 其目的是别让压力机端口存在堵塞现象
3.网络 看网络存不存在丢包
4.应用服务器：sysconf sysctl -a > sysctl.txt 、与数据库连接配置文件
应用日志步骤： 看耗时情况
5.中间件 :tuxedo （域服务器配置） weblogic JDK MQ Congnos nginx F5 等
6.数据库 ：Oracle DB2 infomix 等
7.架构:
--------------------------
参数化策略：每次迭代、每次出现、只取一次
顺序、随机、唯一
#AIX系统：
#1.判断内存不足：svmon -G: virtual值大于size,则表明物理内存不足，换页不可避免，只能在硬件上升级物理内存或者配置用户应用，通过减小应用对内存的需求量来解决。
vmstat:收集内存使用数据和换页数据；fre，avm:表示系统工作所需的页面数；avm > fre,表明换页。
lsps:收集换页空间的使用情况。
---------------------内存泄漏产生的原因-----------------------
1、分配万内存后忘记了回收
2、程序代码有问题，造成没有办法回收
3、某些API函数操作不正确，造成内存泄漏
---------------------------注意：-----------------------------
如果重启机器后，cache没有被释放，可进入/proc/sys/vm中使用echo 2 >drop_caches命令释放cache。
--------------------------------------------------------------
HTTP录制协议关联：
insert--->搜索web_reg_save_param进行关联，关联函数要放在参数字段语句上面，打印日志函数要放在参数字段语句的下面。
登陆的关联最好是登陆的账号或密码
--------------------------------------------------------------
xml格式转换：
1、视图中的选择XML格式
2、格式中选择XML转换格式
编写测试报告时问题分析：
1、对问题分析要深入，排除自身的影响
2、要注意格式的排版
--------------------------------------------------------------
统计当前目录下（包括子目录）所有文件个数
ls -lR |grep "^d" |wc -l
--------------------------------------------------------------
java 程序的项目都需要监控VmRss、Vmsize
VmRss:虚拟内存驻留集合大小。这是驻留在物理内存的一部分，它没有交换到硬盘。它包括代码、数据和栈。
Vmsize:虚拟内存大小。整个进程使用虚拟内存大小，是VmLib、VmExe、Vmdata、Vmstk的总和。
---------------------------------------------------------------
Tuxedo脚本调试：
1、了解服务器端Tuxedo版本，本地控制机安装Tuxedo客户端，配置环境变量
2、了解WSL访问方式（IP:Port）
3、了解研发使用的Tuxedo服务名、数据缓冲类型（如：CARRAY、FML32等）、缓冲区长度（如1024*1024*3）
4、了解这个缓冲区类型的缓冲结构（包括哪些字段，这些字段的属性（数据类型、数据长度等），以及这些字段要放置什么数据，是任意数据还是指定的死数据）
5、了解报文（报文长度、内容、详细信息；哪些数据需要做参数化；调研报文的格式，是否通过在脚本中组装报文，是否可以通过从报文文件中获取报文）
6、了解报文发送后服务器返回的数据内容、长度等，用作在脚本中判断事物是否成功
---------------------------------------------------------------
三层架构:
客户端（表现层） 中间件服务层（业务逻辑层） 数据库服务器层（数据层）
应用weblogic中间件的系统一般采用的B/S架构，绝大部分采用HTTP协议，少量的系统用JAVA编写的客户端，使用的是RMI协议，或J2EE里的协议。
-----------------------------------------------------------------
配置host的路径： C:\windows\system32\drivers\etc
----------------------------------------------------------------
正则表达式：
代码 说明
. 匹配除换行符以外的任意字符
\W 匹配字母或数字或下划线或汉字
\S 匹配任意的空白符
\d 匹配数字
\b 匹配单词的开始或结束
^ 匹配字符串的开始
$ 匹配字符串的结束
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
---------------------------------------------------------------项目调优事项------------------- -------------------------------------------------------------------------------
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
一、ECIF
1、问题描述：性能测试组在生产环境对ECIF系统进行性能测试，截止目前发现的问题主要是10并发过程中发现ESB应用服务器CPU资源消耗过高，在70%左右，并且当中sys%占比较高占资源消耗的50%。
问题分析：经分析一个是CPU资源不足，还有一个原因是应用日志输出过多引起的。
问题解决：应用服务器CPU增加至8C，减少了日志中冗余内容的输出。
2、问题描述：ECIF高并发时出现交易大量报错现象。
问题分析：交易发送处理完，断开连接，但是未收到客户端的端口关闭动作，导致大量端口被占用，端口资源被耗尽。
问题解决：优化了tcp连接参数，调整了系统控制文件（sysctl.conf）里的端口复用和快速回收参数，增加配置参数详细如下:net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_tw_recycle = 1
net.ipv4.tcp_fin_timeout = 30
3、问题描述：性能测试组在生产环境对ESB系统进行性能测试，10并发过程中发现ESB应用服务器CPU资源消耗过高，在80%左右。
问题分析：经技术人员分析原因是应用日志输出内容过多，导致cpu资源被大量消耗引起的。
问题解决：1．优化异步写数据库日志线程池,将JMS队列线程数由20调至50个线程,同时修改了代码处理逻辑。
2．优化内部服务控制处理流程。
3．关闭非必要输出日志。
二、财务
1、问题描述：发票认证结果交易容量测试过程中，随着并发数的梯度增加，应用服务器CPU资源消耗和交易TPS无明显增长，交易响应时间明显变长。
问题分析：经与技术人员调试分析，该交易由于业务需要，凭证号码必须是按照顺序生成，凭证号生成过程中采用单线程方式，因此导致该问题和现象。
问题解决： 技术人员分析，要实现顺序生成凭证号的业务规则只能采用单线程方式，并且发票认证业务属于审批类交易，在生产上属于权限较高的业务，并不存在高并发高压力的问题，目前测试的结果，从响应时间和TPS以及资源消耗情况来看，都能满足今后生产需要，故经项目组同意该问题暂不处理。
2、问题描述：在对F5可靠性测试过程中，当停掉一台应用服务和重启服务后，TPS未能恢复到最初水平，交易一直报错，错误提示：发票代码：XXXXXX,发票号码XXXXXX，数据已经被锁定，请等待；并且出现终止测试场景，曾被停掉服务的应用服务器cpu资源仍然占用100%现象。
问题分析：经与技术人员分析，交易在执行过程中，程序需要对该数据进行加锁处理，当交易完成后再释放锁，但未考虑执行交易过程中出现交易中断，释放锁的处理逻辑，因此造成死锁现象发生。
问题解决：取消了程序中加锁的代码。
三、新柜面、无纸化
1、问题描述：执行稳定性测试，在info级别下会记录大量的日志，无法支撑24小时，另外应用服务器的SWAP分区因内存不足被逐渐消耗。
问题分析：硬件资源内存不足导致。
问题解决：将日志级别修改为error级别，服务器的SWAP分区不在被占用。
2、问题描述：执行单交易测试，场景在10用户并发下执行2小时30分钟，随着交易时间越来越长，TPS从最高91笔/s降到最低61笔/s，呈现明显下降的趋势；响应时间从最低0.108s上升到最高0.16s,呈现明显上升的趋势；发现数据库CPU资源使用率也越来越高，呈现明显上升趋势，CPU资源使用率从最低65.8%上升到最高91.5%；数据库磁盘I/O基本维持在30%左右，呈现逐步下降的趋势。
问题分析：通过awr报告分析其中一条sql：select ELECDOCDATE, ELECDOCNO from ab_elec_doclog where CHANELDATE = :1 and CHANELCODE = :2 and VOUTYPE = :3 and PRINTNO = :4 and STATUS = '1'占用65%以上的cpu时间，并且该sql执行了全表扫描。
问题解决：项目组优化了ab_elec_doclog表的索引字段，并将索引使用的表空间从系统表空间移到用户表空间。
3、问题描述：执行单交易测试过程中，发现在10用户并发下，TPS150，数据库I/O仅7M/秒，但数据库服务器磁盘利用率高达50%以上，当加压到20并发时，磁盘利用率就超过80%。
问题分析：通过awr报告分析目前每成功一笔交易数据库需要commit 4次，当前10个并发tps为150，就意味着数据库一秒钟commit次数达到150*4=600次，因此导致磁盘利用率和cpu过高的现象出现。
问题解决：项目组调整了数据库Commit次数，由原来的4次调整为3次，数据库的磁盘繁忙率在一定程度上得到了缓解，但是当TPS超过300仍然会出现该情况。
四、黑名单
1、问题描述：执行负载测试，当并发用户数从50增加到100时，TPS未相应增加仍然保持在300左右，应用服务器和数据库服务器的cpu使用率也无明显变化，仅交易响应时间从0.15秒增长到0.3秒左右。
问题分析：经多次测试调试，发现日志对交易响应时间和TPS影响较大，当日志级别为error时，50并发tps可达2000；日志级别为info时，50并发tps仅300。
问题解决：优化应用程序中日志处理逻辑，去除了冗余日志的输出并把不必要的日志输出调成了debug，必要的日志调成info级别。
五、统一回单
1、问题描述：单交易基准测试从场景发现回单打印交易在1vu下执行100次迭代，平均响应时间达到4.5秒、回单预览交易平均响应时间达到2.7秒，超过性能指标2秒，且数据库CPU大于20%。
问题分析及解决：有执行效率过低的sql导致数据库CPU偏高，响应时间较长。优化sql，增加索引，问题得以解决。附优化后sql：
2、问题描述：单交易负载测试20vu并发，数据库CPUwait%较高，磁盘占用率超过80%。
问题分析及解决：代码中有记录日志的操作，并发压力时数据库频繁写日志，导致磁盘IO过高。关闭数据库日志操作，问题得以解决。
3、问题描述：单交易负载测试20vu并发，数据库CPUsys%较高，导致CPU利用率达到100%。
问题分析及解决：未找到原因。更换数据库后，问题得到解决
4、问题描述：容量测试增加并发数后，系统交易平均响应时间逐渐上升，系统处理能力逐渐下降，应用及数据库各项资源指标无明显变化。
问题分析及解决：1.压力上不去：接收报文时将报文map转换成object这一步骤时，方法性能不高，压力卡在这一步。后改动mapToObject方法，提高该方法性能，压力提高。
2.第二次压测时，发现明细账打印响应时间很长，发现是每次明细账打印时都编译模板，造成性能太低。修改打印方法，只编译一次，以后打印都不编译。性能提高，响应速度降低。
5、问题描述：签约交易单交易并发测试过程中，数据库磁盘利用率较高超过80%。
问题分析及解决：签约交易每发生一笔就会对数据库进行两次insert操作和四次select操作，且每执行一次后都要完成一次commit操作，以上均为正常的业务逻辑操作，无法进一步优化；对压力测试场景增加1ms pacing后，20vu并发复测，数据库磁盘利用率下降到48.9%，平均响应时间为19ms，TPS为628.032笔/秒。
六、外部数据管理平台
1、问题描述： 20个并发执行个人客户信用报告查询申请、个人客户信用报告查询详细信息混合场景10分钟，报“接口运行时异常”错误，且响应时间比较长。
问题分析：性能测试环境未铺好，本次是对开发环境进行试压，版本稳定后打包至测试环境。项目组查看后台并经过分析发现，最大线程数是20 ，导致线程池堵塞；计费模块中费用统计同步，配额机制主要统计接口使用次数存在Update操作，导致响应时间比较高。
问题解决：项目组调整了如下内容：
1.最大线程数由20调为1000；
2.计费模块中费用统计由同步调为异步；
3.配额机制主要统计接口使用的次数取消了Upadate操作。
2、问题描述：执行个人客户信息报告查询详细信息交易20并发单交易联调测试，报“接口运行时异常”。
问题分析：项目组查看后台发现费用流水表被删。
问题解决：项目组重建了费用流水表 。
七、网联系统
1、问题描述： 执行身份认证及签约交易40并发、60并发单交易试测，响应时间由0.4秒增长至0.55秒，TPS保持在70左右，应用服务器CPU使用率在45%左右，没有明显增加，最大TPS只能达到250左右TPS，资源使用率在60%左右。
问题分析：1、项目组分析日志查看日志打印时间间隔，发现日志打印的时间慢。
2、根据日志打印定位代码，查看代码块，对代码块进行分析，然后优化接收线程池。
3、根据日志情况进行打印日志输出，然后再进行压力测试，发现不打印日志tps能够达到正常值。
4、根据不打印日志情况优化日志输出方式，采用log4j输出日志。
5、再进压力测试发现单机tps能够达到350。然后再进行log4j版本升级。升级到log4j 2.0版本。
6、再进行压力测试，发现单机tps能够达到400以上。
问题解决：1、优化接收线程池；
2、采用log4j 2.0版本输出日志。
2、问题描述： 进行容量测试压测，发现160并发，tps达到400左右，数据库磁盘IO达到70%左右，继续增加并发至180，tps还是维持在500左右,数据库磁盘IO达到80%左右。
问题分析：项目组查看后台发现是数据库的配置不足导致的，现在的配置是4C4G,生产上是8C16G，故配置提升至8C8G；数据库版本现在是11g，生产上版本是12C，故版本升级至12C,相关内核参数做了调整，问题得到解决。
问题解决：数据库配置由4C4G提升至8C8G，版本由11g升级至12C，数据库内核参数也做了调整，具体oracle 11g内核参数见附件一，oracle 12C 内核参数见附件二。
3、问题描述：进行120并发400TPS的稳定性试压，执行到6小时左右时，数据库CPU达到100%，磁盘IO也达到100%，且数据库内存存在泄漏问题，执行至12小时时，报大量“系统异常错误”，后台报“【信息：表：【EPCC_MSGRGSTR】,数据入库失败,执行存储过程：PRO_EPCC_MSGRGSTR_01执行失败java.sql.SQLException: ORA-01653: 表 EPCC.EPCC_MSGRGSTR 无法通过 8192 (在表空间 EPCC 中) 扩展】”错误。
问题分析：1、项目组查看后台发现系统表空间不足，现有是100g磁盘，没有建立表空间，项目组重新建立表空间，磁盘空间扩至300G。
2、打印AWR报告发现SQL“select trxctgy from epcc_msgrgstr where rpflg=:1 and INSTGID=:2 and trxid=:3 ” 耗时比较长，项目组经过分析，发现索引“EPCC ID1_EPCC_MSGRGSTR Normal RPFLG, INSTGID, TRXID N Y N N tablespace epcc pctfree 10 initrans 2 maxtrans 255 storage ( initial 64k next 1m minextents 1 maxextents unlimited )” 在数据导入数据库时未及时生效。
问题解决：1、项目组重新建立表空间，表空间由32G扩充至160G；
2、重新建立了索引“EPCC ID1_EPCC_MSGRGSTR Normal RPFLG, INSTGID, TRXID N Y N N N tablespace epcc pctfree 10 initrans 2 maxtrans 255 storage ( initial 64k next 1m minextents 1 maxextents unlimited )”。
-------造成数据库繁忙的原因------
1、对数据库的使用过于低效：错误的查询设计、糟糕的应用程序逻辑、对于数据访问框架的配置不正确
2、糟糕的数据库设计与数据结构：表的关联、缓慢的存储视图、缺失的或错误的索引、过期的表统计信息
3、不恰当的数据库配置，例如：内存、磁盘、表空间、连接池等
350
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
