我希望对我网站的1000万用户进行负载测试。该网站是基于Java的Web应用程序。我的做法是为所有链接创建Jmeter测试计划，然后为这1000万用户生成报告，并使用jvisualVM进行性能分析以检查是否存在任何瓶颈。
有更好的方法吗？有没有现成的演示文稿可以参考？由于这是我第一次做，所以任何帮助都将非常有用。
如何使用jmeter和visualVM进行负载测试？
9
- Daemonthread
3
我的目标是支持至少1千万用户。 - Daemonthread
哇，这是一个很大的问题。首先有几个问题：1000万是很多的，这是并发用户还是独立用户？你是否使用本地Web服务器？你是否将Java应用服务器进行集群？你会使用负载均衡器吗？你能说一下你将使用哪个应用服务器吗？是否会有其他依赖项，如数据库等？ - Nicholas
2数据库中有1000万个用户。我可以使用PL/SQL过程来完成这个任务。同时有150个并发用户，没有集群，只有一个暂存机器，没有负载均衡器。应用服务器是Jetty。 - Daemonthread
5个回答
7
您走的方向是正确的，但您的负载限制高了很多。我之所以这么说是因为您的网站可能需要更多的机器来处理1000万个并发用户。单个进程可能会难以处理32K个并发TCP流。此外，还要计算一下实际处理1000万个用户所需的带宽。
现在我不知道您打算在网站上提供什么样的服务，但如果考虑到JVisualVM会使处理速度减慢10倍（或更多），特别是方法跟踪时，同时使用JMeter和JVisualVM就不能真正测量“真实世界”的情况。
当负载较低时，JVisualVM更有用。
要创建一个好的测量，首先确保您有一个良好的基线。使用10个并发用户进行测试，连接JVisuamVM并让其运行一段时间，记录所有有趣的值。
在您有了基线之后，就可以开始添加更多负载。增加10倍的负载（例如：100个用户），观察JVisualVM中的变化。继续进行，直到明显感到JVisualVM会拖慢您的速度。每次添加额外的负载时，请确保已经记录下您感兴趣的数字。将这些数字绘制成图表。
现在...手动插值图表，得出您想要的用户数量。这适用于内存使用、磁盘访问等，但不适用于CPU时间的使用，因为JVisualVM会占用CPU，并给出无效的数字（特别是如果您打开了方法跟踪）。
如果您真的想要达到1000万个用户，我也不会相信JMeter，我会编写一个自己的小测试程序来执行所需的测试。这是可以接受的，因为设置网站处理1000万个用户也需要时间，因此在测试工具上多花一点时间并不浪费。
现在我不知道您打算在网站上提供什么样的服务，但如果考虑到JVisualVM会使处理速度减慢10倍（或更多），特别是方法跟踪时，同时使用JMeter和JVisualVM就不能真正测量“真实世界”的情况。
当负载较低时，JVisualVM更有用。
要创建一个好的测量，首先确保您有一个良好的基线。使用10个并发用户进行测试，连接JVisuamVM并让其运行一段时间，记录所有有趣的值。
在您有了基线之后，就可以开始添加更多负载。增加10倍的负载（例如：100个用户），观察JVisualVM中的变化。继续进行，直到明显感到JVisualVM会拖慢您的速度。每次添加额外的负载时，请确保已经记录下您感兴趣的数字。将这些数字绘制成图表。
现在...手动插值图表，得出您想要的用户数量。这适用于内存使用、磁盘访问等，但不适用于CPU时间的使用，因为JVisualVM会占用CPU，并给出无效的数字（特别是如果您打开了方法跟踪）。
如果您真的想要达到1000万个用户，我也不会相信JMeter，我会编写一个自己的小测试程序来执行所需的测试。这是可以接受的，因为设置网站处理1000万个用户也需要时间，因此在测试工具上多花一点时间并不浪费。
- UnixShadow
2
Unix提出了一个非常好的观点 - 确保您拥有一个良好且稳定的基线，并使用不同数量的并发用户（10、50、100、150）进行一批测试，每个测试运行相同的持续时间，至少为一小时。 - BlackGaff
2在最新的JDK版本中，JVisualVM具有采样分析器，其性能影响微乎其微。这种类型的分析可以在生产服务器上进行，即使在中等负载下也可以实现。 - Denis Bazhenov
3
仅仅因为你的数据库里有1千万用户，并不意味着你需要使用那么多用户进行负载测试。想一想 - 你的网站真的会有1千万 同时 在线的用户吗？对于Web应用程序，100:1的比例是很普遍的，也就是说，在任何时刻，你都不太可能有超过100K的用户。
JMeter能承受那种负载吗？我怀疑。请尝试使用faban。它非常轻量级，可以支持单个虚拟机上的数千个用户。您还可以在创建工作负载方面具有更好的灵活性，并且还可以自动监视整个测试基础架构。
现在进行分析部分。你没有说你正在使用哪个服务器。任何Java应用服务器都会提供足够的监控支持。商业服务器提供漂亮的GUI工具，而Tomcat通过JMX提供广泛的监控。在深入到JVM层之前，你可能需要从这里开始。
对于JVM来说，在运行如此大的性能测试时，你真的不希望使用VisualVM。除了支持这样的负载之外，我假设你正在使用多个应用服务器/JVM实例。主要的性能问题通常是GC，因此使用JVM选项来收集和记录GC信息。您将不得不对数据进行后处理。
这是一项非常棘手的练习 - 祝你好运！
- shanti
2
请查看注释。我指定了数据库中有1000万个用户和150个并发用户。 - Daemonthread
抱歉-我错过了那个。然后重要的是，根据你的目的正确创建工作负载，以访问所有用户或者子集。 - shanti
3
有两种类型的负载测试——瓶颈识别和吞吐量。根据问题，我认为这是关于瓶颈的，所以用户数量有点误导，实际上目标是在给定配置下找到可以改进以增加并发性的区域。
应用程序瓶颈通常分为三类：数据库、内存泄漏或缓慢算法。找到它们涉及将受影响的应用程序承受压力（即负载）一段时间，至少一个小时，也许长达数天。Jmeter是此目的的好工具。其中一件要考虑的事情是启用cookie处理的相同测试（即Jmeter保留cookie并随后每个请求发送），并禁用此功能-有时您会获得非常不同的结果，这很重要，因为后者实际上是某些爬虫对您的站点进行模拟。下面是瓶颈检测的详细信息： 数据库 没有索引或涉及多个连接的SQL语句是频繁的应用程序瓶颈。我处理过的每个数据库服务器，MySQL、SQL Server和Oracle都有一种记录或标识运行缓慢的SQL语句的方法。MySQL有慢查询日志，而SQL Server有动态管理视图来跟踪最慢的运行SQL。一旦您获得了缓慢的语句，请使用解释计划查看数据库引擎正在尝试执行什么操作，使用任何建议索引的功能，并考虑其他策略-例如去规范化-如果这两个选项不能解决瓶颈。 内存泄漏 打开详细垃圾收集日志和JMX监视端口。然后使用提供更好图表的jConsole观察趋势。特别是泄漏通常显示为填充Old Gen或Perm Gen空间。当JVM花费越来越多的时间尝试无法成功进行垃圾收集直到抛出OOM错误时，泄漏是一个瓶颈。
Perm Gen意味着需要将其作为命令行参数增加到JVM中。而Old Gen则暗示有一个泄漏，您应该停止负载测试，生成堆转储，然后使用Eclipse Memory Analysis Tool识别泄漏。 缓慢算法 这更难跟踪。最常见的罪魁祸首是同步、进程间通信（例如RMI、Web服务）和磁盘I/O。另一个常见问题是代码使用嵌套循环（看起来像O（n ^ 2）性能！）。
我发现找到这些问题的最佳方法是生成堆栈跟踪。这些将告诉您在给定时间点所有线程正在做什么。您要寻找的是BLOCKED线程或多个线程都访问相同的代码。这通常指向代码库中的某些缓慢性。
应用程序瓶颈通常分为三类：数据库、内存泄漏或缓慢算法。找到它们涉及将受影响的应用程序承受压力（即负载）一段时间，至少一个小时，也许长达数天。Jmeter是此目的的好工具。其中一件要考虑的事情是启用cookie处理的相同测试（即Jmeter保留cookie并随后每个请求发送），并禁用此功能-有时您会获得非常不同的结果，这很重要，因为后者实际上是某些爬虫对您的站点进行模拟。下面是瓶颈检测的详细信息： 数据库 没有索引或涉及多个连接的SQL语句是频繁的应用程序瓶颈。我处理过的每个数据库服务器，MySQL、SQL Server和Oracle都有一种记录或标识运行缓慢的SQL语句的方法。MySQL有慢查询日志，而SQL Server有动态管理视图来跟踪最慢的运行SQL。一旦您获得了缓慢的语句，请使用解释计划查看数据库引擎正在尝试执行什么操作，使用任何建议索引的功能，并考虑其他策略-例如去规范化-如果这两个选项不能解决瓶颈。 内存泄漏 打开详细垃圾收集日志和JMX监视端口。然后使用提供更好图表的jConsole观察趋势。特别是泄漏通常显示为填充Old Gen或Perm Gen空间。当JVM花费越来越多的时间尝试无法成功进行垃圾收集直到抛出OOM错误时，泄漏是一个瓶颈。
Perm Gen意味着需要将其作为命令行参数增加到JVM中。而Old Gen则暗示有一个泄漏，您应该停止负载测试，生成堆转储，然后使用Eclipse Memory Analysis Tool识别泄漏。 缓慢算法 这更难跟踪。最常见的罪魁祸首是同步、进程间通信（例如RMI、Web服务）和磁盘I/O。另一个常见问题是代码使用嵌套循环（看起来像O（n ^ 2）性能！）。
我发现找到这些问题的最佳方法是生成堆栈跟踪。这些将告诉您在给定时间点所有线程正在做什么。您要寻找的是BLOCKED线程或多个线程都访问相同的代码。这通常指向代码库中的某些缓慢性。
- orangepips
0
我在博客中介绍了我的性能测试步骤：
- 确保服务器（硬件可以按照预发布/生产要求）没有其他可能影响性能的安装。
- 为在数据库中设置用户，可以使用一个过程，并将其作为jmeter测试计划的一部分进行调用。
- 在单独的机器上安装jmeter，以便jmeter不会影响性能。
- 为所有uri创建一个jmeter测试计划（如图1所示），包括响应检查和基于定时器的请求。
- 使用jmeter进行初始基准测试。
- 检查低性能的uri。这些是预期出现瓶颈的点。
- 尝试不同的性能改进选项，但每次只关注一个瓶颈。
- 从第6步中尝试任何一个修复方法，然后进行基准测试。如果有任何改进，请提交更改并从第5步重复。否则，请还原并尝试从第6步中的其他选项。
- 下一步将是使用负载平衡、硬件扩展、集群等。这可能涉及一些物理设置和硬件/软件成本。给出可扩展性选项的结果。
详细解释请参见：http://www.daemonthread.com/2011/06/site-performance-tuning-using-jmeter.html
- Daemonthread
1
链接已损坏。 - tranceholic
网页内容由stack overflow 提供, 点击上面的可以查看英文原文，
原文链接
原文链接