glassfish_GlassFish响应生产中的GZIP压缩

glassfish

关于这一点已经写了很多，这基本上应该是常识，但是与不同的人交谈，并研究Google为提高页面速度所做的努力，在我看来，这个话题值得我们重新考虑。

基础

HTTP压缩（也称为内容编码）是一种公开定义的方法，用于压缩从Web服务器传输到浏览器的文本内容。 HTTP压缩使用gzip和compress之类的公共领域压缩算法来压缩服务器上的XHTML，JavaScript，CSS和其他文本文件。

HTTP 1.1内置了这种基于标准的传递压缩内容的方法，并且大多数支持HTTP 1.1的现代浏览器都支持ZLIB对压缩后的文档进行填充。 换句话说，它们可以自动解压缩压缩文件，从而节省了时间和带宽。

但这很简单。 有什么问题？

为了压缩您的内容，您必须在响应服务器和客户端之间的某个位置执行此操作。 深入研究这一点，您会发现需要注意的几件事：

这应该：

1）…要快
2）…经过生产验证
3）…不要降低应用服务器的速度 4）…可移植且不绑定到应用服务器

让我们去更详细地看一下可以做些什么，以加快GlassFish的速度。

测试页

我试图用一个简单的测试页来运行它。 这是GlassFish的管理控制台中的“编辑网络侦听器”页面（http：// localhost：4848 / web / grizzly / networkListenerEdit.jsf？name = admin-listener＆configName = server-config）。 使用Firebug捕获的我的小型计算机上此页面的基本响应时间（未压缩）：

类型	＃ 要求	大小（kb）	时间（毫秒）
CSS	11	120	125
js	12	460.7	130
html	3	324.3	727
所有	52	1126.4	1380

GlassFish内置压缩

如果您正在运行GlassFish 3.x服务器，那么最明显的就是看他所提供的服务。 您可以简单地“启用HTTP / 1.1 GZIP压缩以节省服务器带宽”（“编辑网络侦听器” => HTTP =>中）。 您只需添加所需的可压缩mime类型（默认值加上：text / css，text / javascript，application / javascript），然后设置最小压缩大小（本例中为1024bytes）。 您必须重新启动实例才能使更改生效。

类型	＃ 要求	大小（kb）	时间（毫秒）	更改 尺寸百分比	更改 ％ 时间
CSS	11	24.9	185	-79,25	48,00
js	12	122,2	55	-73,48	-57,69
html	3	22.6	1470	-93,03	102,20
所有	52	272,4	2350	-75,82	70,29
				-80,39	40,70

查看结果，您平均可以使用压缩节省80％的带宽，但是您通常还需要更长的时间才能提供压缩内容。 我还意识到，您必须尝试使用​​哑剧类型的设置。 检查单个文件实际上具有哪种MIME类型将很有帮助。

Apache mod_deflate

如果您不希望在应用程序服务器上增加额外的负载（这很常见），则可以将其分派给知道如何处理http的人。 这对于Apache的httpd是正确的。 您要查找的模块称为mod_deflate，您可以随配置一起加载它。 我假设您有类似mod_proxy的东西，可以通过您的httpd代理针对GlassFish的所有请求。 比较开始变得有些棘手。 使用mod_proxy意味着您的响应时间大大减少。 因此，将其与对GlassFish的直接请求进行比较将是无效的。 实际上，我所做的是，将平均响应时间与通过Apache的未压缩响应进行比较，然后将大小与GlassFish压缩进行比较。

类型	＃ 要求	大小（kb）	时间（毫秒）	更改 尺寸百分比	更改 ％ 时间
CSS	11	24.9	551	-79,25	-5,97
js	12	122,2	55	-73,48	0,76
html	3	22.6	1470	-93,62	-1,29
所有	52	272,4	2350	-75,97	-5,65
				-80,58	-3,04

没什么大惊喜吧？ 他们都使用gzip压缩，这是一种非常普遍且众所周知的算法。 因此，我没想到压缩效果会发生任何变化。 但是您看到的是，与在GlassFish上运行相比，压缩速度有所不同。 平均开销约为3％，您几乎感觉不到任何变化。 这是一个加号！ 另一个优点是，您可以使用mod_deflate更改压缩级别。 将其从Zlib＃s的默认值设置为最高（9）会给您带来额外的压缩效果，但您看不到总体压缩率高于1％，这也可能是测量上的不准确性。

Google mod_pagespeed

是的 那将是一个很好的附加测试。 但是：我只运行Windows框，并且仍然仅在某些Linux版本上支持二进制文件。 所以，我今天需要跳过它。

压缩过滤器

那里有很多压缩servlet过滤器。 过去，甚至BEA都附带了WebLogic。 我想从今天起，出于稳定性考虑，我不会在生产中使用类似的东西。 我坚信，没有任何理由让您的应用服务器进行任何压缩。 快速压缩内容会占用CPU时间，并且在应用程序服务器上进行压缩会更好地花费在其他工作负载上。 尤其是因为您通常在应用服务器和DMZ httpd之间没有带宽问题。

参考：我们的JCG合作伙伴 Markus Eisele 在生产 Java的企业软件中 使用GlassFish在生产中响应GZIP压缩 。

相关文章 ：

• 一台机器上的多个Tomcat实例
• Tomcat中的零停机部署（和回滚）； 演练和清单
• 调试生产服务器– Eclipse和JBoss展示
• 了解“主机”文件
• 如何解决生产问题

翻译自: https://www.javacodegeeks.com/2011/10/glassfish-response-gzip-compression-in.html

glassfish