基于分布式SOA架构的系统压力测试

发布于 2024-09-05 02:58:11 字数 238 浏览 8 评论 0原文

我们目前有一个包含 20 个 SOA 服务的系统,并且有一个主 mysql 数据库和 2 个从节点。目前我们的数据库中有 10 GB 的数据。我们有一个要求,表中的数据将显着增加。我们希望在实施之前对系统进行压力测试。对于这种分布式环境,什么样的压力测试有意义?

此外,在执行压力测试时,我可以查看延迟和指标,例如为 90% 的服务请求提供服务的延迟是多少。还有其他好的服务指标吗?我应该寻找 mysql 数据库的哪些指标?

谢谢

We currently have a system with 20 SOA services and having a single master mysql database and 2 slave nodes. We currently have 10 GB of data in the database. We have a requirement in which the data in a table is going to be significantly increased. We want to stress test the system before proceeding with the implementation. What kind of stress testing makes sense for this kind of distributed environment?

Also, when performing the stress testing, I can look out for latency and metrics like what is the latency for servicing 90% of the requests for the services. Are there any other good metrics for services? What metrics should I look for the mysql database?

Thank you

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

年华零落成诗 2024-09-12 02:58:11

这里有一些想法:

  1. 设置一个测试数据库并将附加数据加载到您期望增加的表中;使用您期望的增加的倍数,例如,如果您期望表增加 2000 行,则向测试表添加 4000 行。
  2. 在 MySQL 中启用慢速查询日志记录
  3. 确保 SOA 服务器中的日志记录级别足够详细,可以调试压力测试中的错误。
  4. 使用负载测试工具(例如 JMeter)针对每个服务快速连续运行多个请求。使用您期望的每秒请求数的倍数;我通常会增加预期请求数量的 2 倍、4 倍、8 倍等倍。
  5. 依次对每个单独的服务重复上述测试。
  6. 使用“典型”服务组合重复上述测试 - 例如,如果您预计服务 1 的请求数量是服务 2 的两倍,则在测试中反映这一点。
  7. 如果您还想测试可靠性,请尝试在一个或两个 MySQL 从节点离线的情况下重复 JMeter 测试。

JMeter 应该为您提供所需的所有延迟信息。我喜欢使用的 JMeter 的另一个有用的“现实世界”数据点是 90% 查询时间,这是大于或等于 90% 测试响应的响应时间值。

Here are a few ideas:

  1. Set up a test database and load the additional data into the table where you're expecting the increase; use a multiple of the increase you're expecting, e.g if you're expecting the table to increase by 2000 rows then add 4000 rows to your test table.
  2. Enable slow query logging in MySQL.
  3. Make sure the logging levels in your SOA servers are detailed enough to debug errors from your stress test.
  4. Use a load test tool such as JMeter to run multiple requests against each service in rapid succession. Use a multiple of the number of requests per second you're expecting; I usually ramp up with 2x, 4x, 8x etc. times the number of expected requests.
  5. Repeat the above test against each indivudual service in turn.
  6. Repeat the above test with a "typical" mix of services - e.g. if you expect twice as many requests to service 1 than to service 2 then reflect that in the test.
  7. If you want to test reliability as well, try repeating the JMeter tests with one or both of the MySQL slave nodes taken offline.

JMeter should give you all the latency info you need. Another useful "real world" data point form JMeter that I like to use is the 90% query time, which is the response time value that's greater than or equal to 90% of the test responses.

枯寂 2024-09-12 02:58:11

此场景中的想法仍然是尝试对生产中使用的页面请求和帖子进行建模。不同之处在于仅使用 10Gb 当前生产数据的副本来运行负载测试。
然后模拟额外的数据并运行相同的负载测试。您将能够比较使用服务的页面的响应或直接检查服务调用。

然后,您可以看到额外的数据将对您的服务呼叫产生什么影响。

最重要的指标是您期望(或已测量)最常调用的调用的响应时间。

如果发现性能问题,可以分析有关数据库和服务器本身的其他统计信息。

The idea in this scenario is still to try and model the page requests and posts as they are used in production. The difference is to run a load test with just a copy of the 10Gb of current production data.
Then simulate the extra data and run the same load test. You will be able to compare the responses of the pages that uses the services or check the service calls directly.

You can then see what effect the extra data will have on your service calls.

The metrics that are most important are the response times for the calls that you expect (or have measured) to be called most frequently.

Other statistics on the database and servers themselves can be analysed if you discover a performance issue.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文