随着并发用户的增加，事务失败的数量也增加，但事务响应时间影响不大

luming

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

blue_flower

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

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

aboutmay

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

beiyu95

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

blue_flower

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

blue_flower

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

luming

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

blue_flower

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

blue_flower

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

blue_flower

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

blue_flower

原帖由 blue_flower 于 2008-5-22 14:26 发表
出错信息，如附件图所示。
特别是第一个错误，以前都没见过的，不知道是什么

我知道第一个是权限问题了（也是网上朋友帮忙的，谢谢）

blue_flower

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

jimoderen

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

lyscser

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

1. lr_start_transaction("05 查询加人处理任务");
   
2. 
   
3. web_reg_find("Text=待获取",
   
4. "Fail=NotFound",
   
5. "SaveCount=QueryTask",
   
6. "Search=Body",
   
7. LAST);
   
8. 
   
9. web_reg_save_param("workTaskid",
   
10. "LB=getWorkTask('",
    
11. "RB=','",
    
12. "Ord=1",
    
13. "NotFound=ERROR",
    
14. LAST);
    
15. 
    
16. web_submit_data("searchQueueTask.do",
    
17. "Action=http://XXXXX.com.cn:43026/XXXX/searchQueueTask.do",
    
18. "Method=POST",
    
19. "RecContentType=text/html",
    
20. "Referer=http://XXXXX.com.cn:43026/XXXX/searchQueueTask.do",
    
21. "Snapshot=t21.inf",
    
22. "Mode=HTML",
    
23. ITEMDATA,
    
24. "Name=workTableConditionDTO.currentRole", "Value=pos_processing", ENDITEM,
    
25. "Name=workTableConditionDTO.branchCode", "Value=G12", ENDITEM,
    
26. "Name=workTableConditionDTO.startApplySeq", "Value=PA{applySeqNo}", ENDITEM,
    
27. "Name=workTableConditionDTO.endApplySeq", "Value=PA{applySeqNo}", ENDITEM,
    
28. "Name=workTableConditionDTO.policyNo", "Value={policyNo}", ENDITEM,
    
29. "Name=workTableConditionDTO.applicantName", "Value={appName}", ENDITEM,
    
30. "Name=workTableConditionDTO.taskPriorityTypeCode", "Value=", ENDITEM,
    
31. "Name=workTableConditionDTO.startApplyDate", "Value=20081213", ENDITEM,
    
32. "Name=workTableConditionDTO.endApplyDate", "Value={appReadyDate}", ENDITEM,
    
33. "Name=workTableConditionDTO.barCode", "Value={barCode}", ENDITEM,
    
34. "Name=workTableConditionDTO.difficultyTypeCode", "Value=", ENDITEM,
    
35. LAST);
    
36. 
    
37. if (atoi(lr_eval_string("{QueryTask}"))<=0)
    
38. {
    
39. lr_error_message("*=*=*=*=*=*=*=*=*=*=*=*=*=*查询加人处理任务 失败！*=*=*=*=*=*=*=*=*=*=*=*=*=*");
    
40. lr_end_transaction("05 查询加人处理任务", LR_FAIL);
    
41. }
    
42. else
    
43. {
    
44. lr_end_transaction("05 查询加人处理任务", LR_PASS);
    
45. lr_output_message("*=*=*=*=*=*=*=*=*=*=*=*=*=*查询加人处理任务 成功！*=*=*=*=*=*=*=*=*=*=*=*=*=*");
    
46. lr_output_message("*=*=*=*=*=*=*=*=*=*=*=*=*=*查询到的任务ID workTaskid 为：%s", lr_eval_string("{workTaskid}"));
    
47. }

复制代码