所以结论是什么？
并发数=TPS * RT（平均响应时间）在未达到瓶颈时是成立的，达到瓶颈后就开始不成立了？

每个小时的模型的确不同，而且可能取得有问题 (比如业务高峰 1 小时实际是出现在 9:30-10:30，假设这期间交易量为 500w，结果你按整点取 9:00-10:00，结果交易量只有 300w，那你得出处理能力就不同了，业务模型也可能不同)， 1 小时颗粒度还是太粗了，要往小取，比如取高峰半小时，高峰 1 分钟等

看截图用的是 Takin 嘛？

啊哈哈啊哈，楼上太坏了，竟然说破。。。

赞同，某些系统没用并发数的概念，或者说并发数并不指代实际存在的用户，这种时候只看 TPS 是可以的，此时并发数只是增大压力的作用，但是针对某些业务系统而言，并发数是有实际意义的，指代的就是实际存在的用户，这种时候并发数就是有意义的，此时并发数是需要作为一个测试点的。比如某业务系统处理能力要求 300TPS，300TPS 假如可以用 50 并发测到，那么用 100 并发也绝对可测到 (加间隔时间就可以)，那么只考虑 TPS，测试并发数为 50，满足 300TPS 指标，测试通过，但是未验证并发数这个测试点，那么有可能你的系统在 100 并发出现问题，比如无法登陆，或者登陆时间过长等。

7 个小时才一次 fullgc 都不能接受？
另外你 tps 低没看出来跟 fullgc 有啥关系，按你的说法，fullgc 7 小时才触发一次，那这 7 小时之间没有 fullgc tps 为啥也低。。。

这么规律的话是否有可能是 GC？

用 BeanShell 会不会严重影响 JMeter 性能

给的信息太少啦。
不做文件上传时应用服务器资源消耗什么情况，数据库服务器资源消耗什么情况？做文件上传时各服务器资源又是什么情况？
能让开发打更详细的日志分析在文件上传的时候访问主页需 10 分钟的耗时主要在哪里么？
可以抓下线程堆栈看是否有线程阻塞或者死锁等情况。
不知道你们数据库的情况，SQL 语句是否存在性能问题？

你这个要导入自己的 jar 包吧，JMeter 的 Sampler 并没有 Dubbo sample 啊。

请问支持的 ios 版本有限制吗？

最近也想学习。谢谢老哥。
顺便问下，思维导图是工具呀

请问答主用例的编写是没有采用 POM 模式吗？我看百度搜索的例子元素定位是直接写死在测试步骤中的，那如果我有 50 个案例均用到了同一个元素，后面元素定位信息改变了，那我是需要修改 50 个案例吗？

这种密码框一般就是不能直接 sentkey
你可以做 6 次 click

kafka 是哪个版本的呀，比较新的版本已经还有同步异步？

为么万兆网卡瓶颈还在网络上？

打开 APP 的代码好像没有，怎么判断是要打开哪个 APP？

楼主，您好
请问你的 jmeter-results-detail-report_21.xsl 是自己改写过的嘛？
默认是没有 90%Line，95%Line，99%Line 和 QPS 的吧？
谢谢啦