压测tomcat,无法理解其工作机制?

发布于 2022-09-05 03:20:48 字数 323 浏览 16 评论 0

前提:
1.公司进行一台部署有http服务的压测,第一天进行了一晚上(10h)的测试(一次200并发),吞吐量大概56%左右。第二天(期间没有重启过tomcat)也进行了一晚上(10h)测试(一次200并发),吞吐量却降低至16%左右。环境一样,为何落差那么大?
2.我第一天压测1000个并发时,线程数大概是1000+,但是第二天(期间没有重启过tomcat)压测1000并发时,线程数却降到700+,为何之前并发数和线程数成正比,后面却不是了?

上述两个前提,请问tomcat是有什么策略,还是jdbc连接池或者redis连接池导致以上现象吗(使用G1回收机制)?

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

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

发布评论

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

评论(1

单身狗的梦 2022-09-12 03:20:48

这情况就复杂了,其复杂度取决于你的项目运行环境、依赖哪些其他服务。如果你的压测环境复杂(就是很多人都在你这台服务器上运行自己的东西),那压测结果不稳定是可以预见的。

遇到吞吐量下降时,先判断瓶颈在哪里:

  1. 本机资源是否紧张。本机资源主要包括 CPU、内存、网络带宽和磁盘吞吐。这些都需要进行观测排查。

  2. 依赖服务是否紧张,如数据库、外部接口是否处理时间过长。

  3. 如果这些都无法明显定位问题所在,那就进入程序调试阶段了:在每个请求处理过程中,记录每一步的时长,找出瓶颈在哪一步,这个粒度会很细,会要反复修改日志,反复运行,反复观察,但一定会找到问题。

不要一遇到问题就做没有根据的胡乱猜测,这时候“发散思维”帮不上忙,要做的是对问题顺藤摸瓜,严谨分析。

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