首先介绍一下。
我们的 Play2 （版本2.5.10）Web服务以JSON格式提供响应，响应大小可能相对较大：高达350KB。
我们已经在独立模式下运行我们的Web服务一段时间了。我们启用了gzip压缩作为 Play2 ，它将响应体减少了~10倍，即我们有最多约35KB的响应体。
在该模式下，当在Docker容器内的AWS EC2 m4.xlarge（4个vCPU，16GB RAM，750 MBit网络）上运行时，该服务每秒最多可处理200个查询。性能完全受CPU限制，大部分时间（75％）用于JSON序列化，其余时间（25％）用于gzip压缩。业务逻辑非常快，甚至在perf图上也不可见。
现在我们引入了一个单独的前端节点（运行 Nginx ）来处理一些特定的功能：身份验证，授权以及对此问题至关重要的流量压缩。我们希望将压缩从Play2后端卸载到前端，并将这25％的CPU周期用于主要任务。
然而，性能变得更糟，而不是改善！现在我们的Web服务最多只能处理80 QPS。此时，大多数CPU已经被JVM内部的东西消耗掉了。我们的指标显示它不是垃圾收集，它也不在我们的代码中，而是在Play内部。
重要的是要注意，当这个负载（每个响应约为350KB，80 QPS）时，我们会产生~30 MB / s的流量。这个数字虽然很重要，但并没有使EC2网络饱和，所以这不应该成为瓶颈。
我想我的问题如下：是否有人对此问题有解释和缓解计划？关于如何找到根本原因的一些提示也会有所帮助。