我们的restful web服务使用hazecast3.4.2。我们使用IQueue来存储byte[]对象。一个线程将对象放入队列，另一个线程从队列中获取对象。我们使用Jmeter对50个线程进行负载测试。当对象很小(10k以下(时，它工作得很好，应用程序响应时间总是在50ms以下，CPU很低。当物体较大时，例如90k，响应时间将变为500ms。当对象为250k时，响应时间将为2500ms。同时，CPU使用60%-80%。内存大约为60%-80%。
我们的测试服务器是AWS m5.大型：2核8G。Tomcat分配6G内存。
我们试图通过以下方式解决问题：
- 将hazelcast升级至3.12
- 将备份计数更改为0
问题尚未解决。
这里是prod中的高延迟榛子cast健康监视器，prod服务器是8核和16G内存，tomcat分配12G内存：
2019-10-25 15:11:13.078][INFO][com.hazelcast.util.HealthMonitor][ec1-12]:5701[dev][3.4.2]处理器=8，物理内存.total=14.7G，物理内存.free=183.5M，交换空间.total=0，交换空间.free=0，堆内存.已用=1.8G，堆内存.free=8.8G，堆内存.total.10.7G，堆.内存.最大值10.7G，堆栈.内存.已使用/total.17.31%，堆.已使用/最大值17.31%，minor.gc.count=129321，minor.gc.time=2021051ms，major.gc.count=1224，major.gc.time=165825ms，load.process=80.00%，load.system=79.00%，load.systemsAverage=469.00%，thread.count=153，thread.peakCount=198，event.q.size=0，executor.q.async.size=0，executorq.client.size=零，executor q.query.size=00，executo者q.scheduled.size=0%，executo器q.io.size=0，执行器q.system.size=0，executor.q.prorityOperation.size=0，executor.q-response.size=0，operations.remote.size=8，operations.running.size=2，proxy.count=8，clientEndpoint.count=0，connection.active.count=2，client.connection.count=0，connection.count=2
此问题与Hazelcast无关。您看到的是序列化/反序列化大型对象的高延迟的典型情况。
在数据需要从一个点传输到另一个点的任何系统中，数据都必须在原点进行序列化，通过网络传输，并且在发送存储时可能会在目的地进行反序列化(在您的情况下，这取决于配置(。检索时，数据将在源处序列化(如果以前已反序列化(，遍历网络并在目标处反序列化。在您的情况下，您的应用程序将大部分时间花在ser/des中，这从CPU使用情况可以明显看出。
减少延迟的唯一方法是：1.使用Hazelcast序列化，请阅读此处-https://docs.hazelcast.org/docs/3.12.4/manual/html-single/index.html#serialization2.缩小对象的大小