您的位置:首页 > 理论基础 > 计算机网络

HttpCompressionModule 6的一个Bug及使用效果

2004-10-16 14:55 495 查看
为了优化博客园的访问速度,准备采用HttpCompressionModule 6对传输数据进行压缩,下载了HttpCompressionModule 6 , 并按照示例程序中的web.config配置了博客园程序的web.config。示例程序可以运行正常, 可是访问博客园的程序http://localhost/blog却出现错误:“索引和计数必须引用该字符串内的位置。参数名: count”,错误的代码在“System.String.Remove(Int32 startIndex, Int32 count) +0”, 检查了一下配置, 没发现问题。 要解决问题, 看来只有去看HttpCompressionModule的源代码。这时就感到开放源代码的好处, 有问题可以自己去修改源代码, 不然只能向软件的作者提交Bug, 并等待下一版本,显然这样效率是很低的。打开源代码, 找到出错的代码行,立即发现问题所在,原来的代码是这样的:

string realPath = app.Request.Path.Remove(0, app.Request.ApplicationPath.Length+1);
当我访问http://localhost/blog时, app.Request.Path与app.Request.ApplicationPath的值都是blog,这时上面的语句肯定会产生异常。这样的写法只考虑了http://localhost/blog/的地址形式,显然是不全面的。我进行了这样的修改,解决了问题:

string realPath="";
string appPath=app.Request.ApplicationPath;
string path=app.Request.Path;
if(!appPath.StartsWith("/"))
if(!appPath.EndsWith("/"))
if(path.StartsWith(appPath))


{


realPath = path.Remove(0,appPath.Length);


}
使用效果:
使用HttpCompressionModule自带的Fetch工具进行测试,测试结果如下:



测试结果说明:
第一行数据是未使用HttpCompressionModule的测试结果。
第二行数据是使用deflate压缩算法进行压缩后的测试结果。
第二列数据是Web服务器传递到浏览器的文件大小。很明显,压缩后传输数据大大减少,有效地节约了带宽。
TTFB—首字节平均响应时间(Gets the number of milliseconds that have passed before the first byte of the response was received.)
TTLB—末字节平均响应时间(Gets the number of milliseconds that passed before the last byte of the response was received. )
Transit—传输数据到浏览器的时间。
从测试结果可以看出, 采用HttpCompressionModule后访问速度有明显改善。
内容来自用户分享和网络整理,不保证内容的准确性,如有侵权内容,可联系管理员处理 点击这里给我发消息
标签: