luming 发表于 2008-5-21 16:03:54

你可以在运行的时候，看看内存占用。
就是有一堆的mmdrv.exe，你看看每个用多少内存，估计一下就行了。

blue_flower 发表于 2008-5-21 16:47:11

回复 41# 的帖子

谢谢！请问那一堆的mmdrv.exe在哪可以看到呢？
---在“系统进程”里看：）

[ 本帖最后由 blue_flower 于 2008-5-28 09:49 编辑 ]

aboutmay 发表于 2008-5-21 16:55:00

一般我遇到这个问题都是先看看是不是参数化迭代那里出了问题。

beiyu95 发表于 2008-5-21 17:08:09

1G用户能支持多少用户不好说，你自己试一下。只要负载产生机不过载就行了，否则测出来的误差太大。一个虚拟用户占多数内存，归根到底取决于你业务的复杂程度和对内存的使用（after all, 虚拟用户就是一个线程/进程）。

blue_flower 发表于 2008-5-21 17:19:00

负载产生机的可用内存基本上都还有１３％左右，应该不算过载吧

blue_flower 发表于 2008-5-21 17:22:10

回复 43# 的帖子

参数化迭代那里，我通过扩展日志来看，在回放时很正常．不过在场景中运行时它就好象总是同一个用户了，相同的用户名，很奇怪，不过用户ＩＤ是不同的．

luming 发表于 2008-5-22 11:25:33

看系统进程啊，其实只要内存没有用光，启动再多的用户问题都不大。
更多的瓶颈反而在网络上。

blue_flower 发表于 2008-5-22 12:41:33

哦，内存很少用光了的。倒是经常有Error: Failed to connect to server "192.168.1.111:8899": Connection refused这类错误出现.

blue_flower 发表于 2008-5-22 14:26:53

出错信息

出错信息，如附件图所示。
特别是第一个错误，以前都没见过的，不知道是什么

blue_flower 发表于 2008-5-28 09:10:49

随着并发用户的增加，事务成功率不高，但响应时间没有很大响应，经过分析，认为应该是数据库的SQL语句引起的

blue_flower 发表于 2008-5-28 09:13:03

原帖由 blue_flower 于 2008-5-22 14:26 发表 http://bbs.51testing.com/images/common/back.gif
出错信息，如附件图所示。
特别是第一个错误，以前都没见过的，不知道是什么
我知道第一个是权限问题了（也是网上朋友帮忙的，谢谢）

blue_flower 发表于 2008-5-28 09:17:41

这个问题得到了很多朋友的支持和帮忙，我非常感谢大家。虽然目前问题还没有完全解决，但从大家的解答中我得到了不少新的知识和看法，真的很感谢各位朋友！

jimoderen 发表于 2011-5-11 15:11:28

可以试试下边的方法：
在负载生成器的注册表HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters里，有如下两个键值：
TcpTimedWaitDelay
MaxUserPort
1,这里的TcpTimedWaitDelay默认值应该中是30s，所以这里，把这个值调小为5s（按需要调整）。

lyscser 发表于 2011-5-11 15:52:40

1、从100到600并发增加，但是响应时间却没有下降，是否说明在100之前系统的处理能力已经达到极限了呢？建议从10到100，10个加一次，步进式测试，观察tps和throughout曲线走势，加压到响应时间不动，吞吐量曲线趋于直线的那个点应该就是并发数极限了。
2、加了检查点失败的反而变多，是否说明没有加检查点的时候运行的成功基本都是假的呢？建议http模式测试多使用这种模式写脚本，可能效果更加可信一些：
lr_start_transaction("05 查询加人处理任务");

web_reg_find("Text=待获取",
"Fail=NotFound",
"SaveCount=QueryTask",
"Search=Body",
LAST);

web_reg_save_param("workTaskid",
"LB=getWorkTask('",
"RB=','",
"Ord=1",
"NotFound=ERROR",
LAST);

web_submit_data("searchQueueTask.do",
"Action=http://XXXXX.com.cn:43026/XXXX/searchQueueTask.do",
"Method=POST",
"RecContentType=text/html",
"Referer=http://XXXXX.com.cn:43026/XXXX/searchQueueTask.do",
"Snapshot=t21.inf",
"Mode=HTML",
ITEMDATA,
"Name=workTableConditionDTO.currentRole", "Value=pos_processing", ENDITEM,
"Name=workTableConditionDTO.branchCode", "Value=G12", ENDITEM,
"Name=workTableConditionDTO.startApplySeq", "Value=PA{applySeqNo}", ENDITEM,
"Name=workTableConditionDTO.endApplySeq", "Value=PA{applySeqNo}", ENDITEM,
"Name=workTableConditionDTO.policyNo", "Value={policyNo}", ENDITEM,
"Name=workTableConditionDTO.applicantName", "Value={appName}", ENDITEM,
"Name=workTableConditionDTO.taskPriorityTypeCode", "Value=", ENDITEM,
"Name=workTableConditionDTO.startApplyDate", "Value=20081213", ENDITEM,
"Name=workTableConditionDTO.endApplyDate", "Value={appReadyDate}", ENDITEM,
"Name=workTableConditionDTO.barCode", "Value={barCode}", ENDITEM,
"Name=workTableConditionDTO.difficultyTypeCode", "Value=", ENDITEM,
LAST);

if (atoi(lr_eval_string("{QueryTask}"))<=0)
{
lr_error_message("*=*=*=*=*=*=*=*=*=*=*=*=*=*查询加人处理任务 失败！*=*=*=*=*=*=*=*=*=*=*=*=*=*");
lr_end_transaction("05 查询加人处理任务", LR_FAIL);
}
else
{
lr_end_transaction("05 查询加人处理任务", LR_PASS);
lr_output_message("*=*=*=*=*=*=*=*=*=*=*=*=*=*查询加人处理任务 成功！*=*=*=*=*=*=*=*=*=*=*=*=*=*");
lr_output_message("*=*=*=*=*=*=*=*=*=*=*=*=*=*查询到的任务ID workTaskid 为：%s", lr_eval_string("{workTaskid}"));
}
页: 1 2 [3]
查看完整版本: 随着并发用户的增加，事务失败的数量也增加，但事务响应时间影响不大