用 java 请求呢，在内部实现 sdk 的调用？

您好，还在招人吗？是什么公司？

不太赞同第一条。业务的复杂度不一样，难度肯定很高，出错的几率也会越大。不能单单只看这一个指标吧。还有比如 a 同学一年发布 100 次业务，b 同学一年发布 10 次业务。这样看线上故障 + 漏测率。是不是不太公平啊。

质量保障 + 工作效能都要有吧，现在都在降本增效。

看到有个好的归宿，替你感到开心。加油

嗯，我其实就是想验证下，机器支持的并发数已经到上限了，会有什么表现。或者怎么验证已经到上限了。

了解。集合点也不是并发请求的吧。我们内部会有一些线程池和队列的测试。例如配置 threads=1000，100 并发，tps=1000 并不会出触发线程池异常。反而 1000 并发，会触发线程池异常。

可以解决问题，但是一般前期需要评估资源的

真实场景，其它还是要看压测接口，不同的场景，并发数会有差异的吧。

祝福，一路好运。

目前看是的，这个最优是怎么评估出来呢？

好的。明白了，多谢大佬。

明白。在实际的并发测试过程中，不同的接口要在压力机找到能够支持多大的并发数，然后通过分布式的方式达到高并发的模拟吗？

是被测试的机器吗？

是的。从被测机器上看实际并不是并发 10000。那实际并发数量什么情况下等于线程数量呢？

还有个问题，jmeter 创建 10000 个线程，应该不是并发请求的吧。是循环发送请求的吗？

我从被测试服务线程数看，并不是预期的 jmeter 集合点并发请求的值。

压力机看打印的日志，开始时间到结束时间大概是 40s 左右。

分布式 summary 中 active 就是两台的总和的。

之前也有怀疑是这个问题，现在的脚本中没有结果树和性能统计。

这个证，有用吗？？

看了源码，大概找到问题了， 在取精度的时候。使用的函数时 getInt，

当精度是 000 时，取出是 0

不是，如果时间精度值不是 000，返回是正常的。比如：数据库中 2023-10-18 17:06:19.247，返回也是 2023-10-18 17:06:19.247。，如果数据库中是 2023-10-18 17:06:19.000，返回结果就是 2023-10-18 17:06:19.0，精度丢失两位。

是的。之前还有需求，现在都是降本增效，搞不懂动啦

嗯。我们接口有提供给外部的。