You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@jakarta.apache.org by bu...@apache.org on 2010/09/09 08:52:02 UTC
DO NOT REPLY [Bug 49904] New: Performance problem : I cann't use
Jmeter to simulate stress enough
https://issues.apache.org/bugzilla/show_bug.cgi?id=49904
Summary: Performance problem : I cann't use Jmeter to simulate
stress enough
Product: JMeter
Version: 2.4
Platform: HP
OS/Version: Linux
Status: NEW
Severity: major
Priority: P2
Component: Main
AssignedTo: notifications@jakarta.apache.org
ReportedBy: higkoo@tom.com
Before:
Master – the system running Jmeter GUI, which controls the test
Slave – the system running jmeter-server, which takes commands from the GUI
and send requests to the target system(s)
Target – the webserver we plan to stress test
Resion:
The slave send a request to Target , and also send the result to Master.
The Master is not stronger than the Target Web server.
So The Master cost all cpu , either there're 40 slaves , the target server
is not busy.
If
I do not create result data,Jmeter works well.
Else
If I create even any listener or just witer result to a file,the Master
will be bttleneck !
Also see this blog:
http://hi.baidu.com/higkoo/blog/item/82f97038de5fc0fcb211c7b4.html
I test with LoadRunner , It tells me target could deal with more 40000
Hits/Second.
How can Jmeter do this ?
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscribe@jakarta.apache.org
For additional commands, e-mail: notifications-help@jakarta.apache.org
DO NOT REPLY [Bug 49904] Performance problem : I cann't use Jmeter
to simulate stress enough
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=49904
Sebb <se...@apache.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|REOPENED |RESOLVED
Resolution| |INVALID
--- Comment #5 from Sebb <se...@apache.org> 2010-09-18 21:10:56 EDT ---
Bugzilla is not a support forum.
Please subscribe to the JMeter user mailing list and post there. See:
http://jakarta.apache.org/site/mail2.html
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscribe@jakarta.apache.org
For additional commands, e-mail: notifications-help@jakarta.apache.org
DO NOT REPLY [Bug 49904] Performance problem : I cann't use Jmeter
to simulate stress enough
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=49904
Sebb <se...@apache.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |INVALID
--- Comment #3 from Sebb <se...@apache.org> 2010-09-09 10:50:06 EDT ---
Bugzilla is not a support forum.
Please subscribe to the JMeter user mailing list and post there. See:
http://jakarta.apache.org/site/mail2.html
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscribe@jakarta.apache.org
For additional commands, e-mail: notifications-help@jakarta.apache.org
DO NOT REPLY [Bug 49904] Performance problem : I cann't use Jmeter
to simulate stress enough
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=49904
--- Comment #2 from higkoo <hi...@tom.com> 2010-09-09 05:13:19 EDT ---
Description BUG:
Resion --> Reason
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscribe@jakarta.apache.org
For additional commands, e-mail: notifications-help@jakarta.apache.org
DO NOT REPLY [Bug 49904] Performance problem : I cann't use Jmeter
to simulate stress enough
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=49904
higkoo <hi...@tom.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |REOPENED
URL| |http://hi.baidu.com/higkoo/
| |blog/item/82f97038de5fc0fcb
| |211c7b4.html
Resolution|INVALID |
--- Comment #4 from higkoo <hi...@tom.com> 2010-09-18 07:58:50 EDT ---
Recently study the use of Jmeter,unespectedly encountered the bottleneck of
test tool
Mainly because I use Jmeter to do the test of interfaces performance, the
tested server performance is better
Using LoadRunner test the maximum hits per-second nearly 3 million,nearly 40
load machine CPU near saturation
In the same test environment to use Jmeter for Performance testing, load
machines CPU use less than 30%, while the Jmeter console CPU exhausted.
I analyze it:
In a GUI and without GUI testing process, do not add any listener. The results
showed very little pressure on the console, remote load machine resources were
used well again. That is say,the bottleneck is to collect and analyze data,and
the Jmeter results kept the original data. Remote load machine will immediately
upload the data to the console, this has led to Jmeter console and tested WEB
server were playing the same role.
The Jmeter's natural performance was inferior to the special WEB server,
resulting in the emergence of bottlenecks.
Analysis process in details recorded to the blog:
http://hi.baidu.com/higkoo/blog/item/82f97038de5fc0fcb211c7b4.html
Because the tested interface can not be external, the person who need to
reproduce the problem can install a test server Nginx server:
http://wiki.nginx.org/NginxChs
when compile,you should add --with-http_stub_status_module parameters on
it.
Then in conf/nginx.conf add such a paragraph:
location / status (
stub_status on;
access_log off;
)
Then with http://serverip:port/status as the test address to do performance
test can be reproduced.
I wonder if you have the similar problems, or have any good suggestions?
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscribe@jakarta.apache.org
For additional commands, e-mail: notifications-help@jakarta.apache.org
DO NOT REPLY [Bug 49904] Performance problem : I cann't use Jmeter
to simulate stress enough
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=49904
--- Comment #1 from higkoo <hi...@tom.com> 2010-09-09 02:55:56 EDT ---
最近在研究JMeter的使用，不料遇到测试工具自身有瓶颈。
主要原因是由于本人使用Jmeter做接口性能测试，而被测试的服务器性能比较好。
用LoadRunner测试每秒点击率最高可近3万，近40台负载机CPU近饱和。
而在同样的测试环境下使用Jmeter进行性能测试，负载机CPU用不到30%，而Jmeter控制台CPU耗尽出现瓶颈。
我分析了一下：
在有GUI和无GUI的测试过程，不添加任何监听器。结果发现控制台压力非常少，远程负载机的资源很好地利用起来了。也就是说瓶颈在于收集和分析数据，而Jmeter结果里保存的是原始数据。远程负载机的数据会实时上传到控制台上，这样导致Jmeter控制台和被测试的WEB服务器担当相同的角色。
而Jmeter本身性能自然不如专门的WEB服务器，所以导致瓶颈的出现。
分析过程详细记录到博客里了：
http://hi.baidu.com/higkoo/blog/item/82f97038de5fc0fcb211c7b4.html
由于被测试的接口无法对外，需要重现问题的朋友可以在测试服务器上安装一个Nginx服务器：http://wiki.nginx.org/NginxChs
。
在编译的时候加上 --with-http_stub_status_module 参数就可以了。
然后在conf/nginx.conf里加上这么一段：
location /status {
stub_status on;
access_log off;
}
然后以： http://serverip:port/status 为测试地址进行性能测试即可重现。
------------------------------------------------
不知各位神仙有没遇到类似的问题，或有什么好的建议？
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscribe@jakarta.apache.org
For additional commands, e-mail: notifications-help@jakarta.apache.org