所以结论是什么？
并发数=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 啊。