1

我正在开发一个 Web 应用程序，其动态内容由运行在 JBoss 容器中的 servlet 生成，静态内容/负载平衡由 Apache + mod_jk 处理。

客户端使用 jQuery 向处理它们的 servlet 发出 AJAX 请求，然后生成大型 JSON 响应。

我注意到的一件事是，原作者选择使用下面的方法手动压缩 servlet 中的输出流。

 gzout = new GZIPOutputStream(response.getOutputStream());

这可以在 Apache 端使用 mod_deflate 处理吗？如果你能做到这一点，它是否被认为是更好的做法，你能解释为什么或为什么不？

4

2 回答 2

1

我相信在您的情况下在 Apache 中应用 HTTP 压缩更有意义。

如果服务器被正确配置为压缩这种类型的响应（应用程序/json，如果服务器端代码设置了正确的内容类型），那么无论如何在手动压缩之后它都会被浪费地重新压缩。

另外，如果不支持 gzip 的客户端发出请求，这里会发生什么？如果您在服务器级别压缩响应，它将根据请求的接受编码标头自动适当地响应。

于 2011-05-26T14:55:25.730 回答
0

一些额外的研究显示了几个很好的选择。

问题：

  1. Apache 和 Jboss 之间存在一个网络通道。如果在 jboss 端没有任何类型的压缩，您将在 Apache 和您的客户端之间遇到相同的延迟和带宽问题。

解决方案：

  1. 您可以在 Apache 上使用 mod_deflate 并接受来自 jboss 的未压缩响应并在交付给您的客户之前进行压缩。我可以看到这在某些网络拓扑中是有意义的（由 Dave Ward 提出）。

  2. 您可以应用 Java EE 过滤器。这将在响应存在于 JBoss 容器之前过滤压缩它们的响应。这具有在 JBoss 级别进行压缩的好处，而在您的业务 servlet 中没有一堆讨厌的 GZIP 相关代码。

  3. JBoss 默认使用 Tomcat 作为其 Servlet 引擎。如果您导航到 $JBOSS_HOME/deploy/jbossweb-tomcat55.sar，您可以编辑 server.xml 文件以打开 HTTP/1.1 连接器上的 'compression=on' 属性。这将压缩从容器出站的所有响应。

2 和 3 之间的权衡是为不同的 servlet 压缩块餐或压缩所有响应。

于 2011-05-26T15:56:22.363 回答