帮忙分析下此图，为什么Vuser数已经下降了，响应时间才开始攀升？

larrygao

这是一个访问页面500并发的图~为什么Vuser窜到500的时候，响应没有~~然后开始下降了，响应才慢慢攀升。。。
谢谢~

firemonth

估计服务器荡了,要其它日志分析

larrygao

不应该是服务器当了啊~在刚冲上500的时候，服务器CPU占用率是100%，也就是4秒时间就降到了10%以下。。。可用内存也有很多~看不出当的迹象啊。。。
会不会是WEB服务器的问题？用的是IIS6.。。

dingdingdang7

应该是服务器给当了吧。
你可以手工操作一下界面，或者登陆服务器看一下，

larrygao

服务器应该没当啊~在服务器上操作东西很顺畅啊。。。

liuyong_100

查查数据库啊，看实际的结果啊

larrygao

查不了数据库的情况。。。数据库是MYSQL~在LR里面不能监视

jut984907

能否多运行一段时间（比如30分钟左右），应该能看得更清楚些了

jackloo

如果你的程序需要处理一段时间后才能有反馈，那么在开始的一段时间内，它当然没有transaction了。
通常你会看到transaction的时间应该在20多秒以上。

pcl2004_27

通过楼主的图谱上来看，应该错误分析了图谱，没有真正把transaction弄懂

楼主观察的时 action_transaction 这是一个具体的action的响应时间，而action在脚本处理中是包含了很多请求,比如在脚本设计中
假设 下边脚本action包含，登陆，购物（购物操作需要包含放入购物篮，确认信用卡等操作，假设有4步）
action()
{
    web_url(首页)；
    web_submit_data(登陆)；
    ''''' 购物操作
    web_link(填写个人信息)
    web_link
    web_link
    web_submit_form(提交购买)
}
脚本需要运行总耗时20秒，打开首页登陆大约要用6秒。
从上可以看出其实购物操作是比较耗时的操作，他有4步操作。如果在这个脚本中购物操作加入并发，按照设计的计划，100个总用户，立即开始增加，持续运行5秒，然后每5秒5个用户退出，并发策略设置为30个用户并发，那么场景为了达到30个并发，会等待用户达到30个用户的时候才会开始响应，也就是7秒的时候才有用户开始操作购物（这还是100个用户运行最快的所用时间），他会等待其他用户陆续执行到这里才开始运行，那么这个例子就很可能出现楼主的图谱，用户在下降了才有响应时间，因为5秒后才有退出的用户。

所以从上边的分析过程来看，不具有分析效果，大家也看得出来其实用户更关心的是具体的操作响应时间，比如登陆和购物，而action的相应时间到底是哪个引起性能问题的就无从分析了。
应该把脚本进行分解并在相应的操作业务流程中加入transaction，这样分析才会知道到底哪个业务真的有问题。