LoadModule headers_module modules/mod_headers.so
LoadModule deflate_module modules/mod_deflate.so
设置压缩比率,取值范围在 1(最低) 到 9(最高)之间,不建议设置太高,虽然有很高的压缩率,但是占用更多的CPU资源.
DeflateCompressionLevel 3
AddOutputFilter DEFLATE html xml php js css
<LOCATION />
SetOutputFilter DEFLATE
BrowserMatch ^Mozilla/4 gzip-only-text/html
BrowserMatch ^Mozilla/4\.0[678] no-gzip
BrowserMatch \bMSIE !no-gzip !gzip-only-text/html
SetEnvIfNoCase Request_URI \\.(?:gif|jpe?g|png)$ no-gzip dont-vary
SetEnvIfNoCase Request_URI .(?:exe|t?gz|zip|bz2|sit|rar)$ no-gzip dont-vary
SetEnvIfNoCase Request_URI .(?:pdf|mov|avi|mp3|mp4|rm)$ no-gzip dont-vary
Header append Vary User-Agent env=!dont-vary #对代理的设置
</LOCATION>
下面二个测试网站
http://www.whatsmyip.org/mod_gzip_test/
http://www.gidnetwork.com/tools/gzip-test.php
测试数据对css
Original Size: 44 KB
Gzipped Size: 10 KB
Data Savings: 77.27%
测试数据js
Original Size: 6 KB
Gzipped Size: 2 KB
Data Savings: 66.67%
测试数据php
Original Size: 62 KB
Gzipped Size: 15 KB
Data Savings: 75.81%
上面只是随机拿的几个数据,看的出来,使用了gzip压缩后文件小多了.
另外讲一下,有关squid对gzip的处理
在squid中,对同一个URL只保留一份缓存。对于如果不同browser(是否支持压缩)如果频繁交替访问,例如:对某个cache住的目标,一个http/1.0请求可能会导致squid强制更新其缓存。但接下来的另一个http/1.1请求又会导致squid再次更新缓存。这样那squid缓存数据就要频繁更新,这就极大的降低了cache命中率。
不过还好,现实环境中不支持压缩的browser毕竟是很少的情况,所以对于缓存命中率的降低很有限.
1,最后是在没有打sp2补丁下就安装iis,就不会提示无法复制文件了。
2,假如已要打上了sp2补丁安装iis,出现提示无法复制文件的时候
(1),给他一个路径是windwos/system32里面试试(一般情况下可以找到)
(2),如果不行的话就点击开始->运行->
esentutl /p %windir%/security/database/secedit.sdb
然后会有一个警告框,确定就可以了。
总结,据查是因为microsoft的win2003打上sp2补丁后数据库文件有损,具体原因可以在microsoft的官方网站上查到
由于要用asp写点小程序,需要在自己的2003 sp2 的系统安装iis,这个工作很简单,就不描述过程了,没想到安装过程居然提示C:\WINDOWS\ServicePackFiles\i386里无法找到需要的文件,提示插入sp2光盘。找了张安装这个系统时用的光盘,也没管它是sp1还是sp2丢进光驱,再来一遍。问题依旧。
纳闷了。细细想了想,我这台机子貌似安装2003后打过次sp2的补丁吧,莫非和这个有关系。驱猫上网,问了下google,居然真是这个问题,在某人blog里发现
立即按作者提供的方法操作
没想到又提示错误
Microsoft Windows [版本 5.2.3790](C) 版权所有 1985-2003 Microsoft Corp.
C:\Documents and Settings\Administrator>esentutl /p windir/security/database/secedit.sdb
Microsoft(R) Windows(R) Database Utilities Version 5.2 Copyright (C) Microsoft Corporation. All Rights Reserved.
Error: Access to source database 'windir/security/database/secedit.sdb' failed with Jet error -1811.
Operation terminated with error -1811 (JET_errFileNotFound, File not found) after 147.500 seconds.
仔细一看,原来是路径错误,无法找到数据库。
这样再来一遍
解决方法:开始-》运行-》esentutl /p %windir%/security/database/secedit.sdb
提示:
C:\Documents and Settings\Administrator>esentutl /p %windir%/security/database/secedit.sdb
Microsoft(R) Windows(R) Database UtilitiesVersion 5.2 Copyright (C) Microsoft Corporation. All Rights Reserved.
Initiating REPAIR mode...
Database: C:\WINDOWS/security/database/secedit.sdb
Temp. Database: TEMPREPAIR44784.EDB
Checking database integrity.
Scanning Status (% complete)
0 10 20 30 40 50 60 70 80 90 100
|----|----|----|----|----|----|----|----|----|----|
...................................................
Integrity check successful.
Note:
It is recommended that you immediately perform a full backup of this database. If you restore a backup made before the repair, the database will be rolled back to the state it was in at the time of that backup.
Operation completed successfully in 1.984 seconds.
问题解决。
这个演示页面的功能很简单,我是使用下面的代码去访问了一下数据库
using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;
using System.Web.UI;
using System.Web.UI.WebControls;
using System.Data.SqlClient;
namespace WebApplication1
{
public partial class _default : System.Web.UI.Page
{
protected void Page_Load(object sender, EventArgs e)
{
using(var conn = new SqlConnection("server=(local)\\sqlexpress;database=northwind;integrated security=true"))
{
conn.Open();
Response.Write(conn.State.ToString());
}
}
}
}
请注意,这里我并没有指定用户名和密码,而是使用了integrated security=true。这通常称为“信任连接”或者“集成验证”。这个问题,我下面还会解释。
大家可以看到,网站能正常工作。功能没有什么了不起的,这是一个简单的演示而已。但是下面大家思考一个问题:
假设app_pool_test 这个帐号的密码因为什么原因需要修改(这个很正常,很多公司都有密码修改策略的),那么
1.网站还是否能正常打开?
2.数据库还是否能访问?
我这里就做一个测试,我现在将帐号的密码修改掉
奇怪的是,我们会发现网站照样能打开,数据库居然也照样能访问得上。
首先,这里你应该会有一个疑问:这是为什么呢?难道改了密码没有生效吗?到底什么时候会生效呢?
我们接下去做实验。假使当前这个服务器,因为某种原因(例如安装补丁包),需要重新启动。或者你自己因为某个原因,需要对IIS进行重启,例如执行了下面的命令
然后,我们再次尝试打开刚才那个网页,就会发现如下的错误
一般而言,503错误都是表示后台的Application Pool存在问题,我们到IIS中查看,确实发现它被停止了
而且你还会发现,无论你如何启动,只要页面刷新一下,它就又停止了。
除非,你再次在它这里将正确的用户名和密码设置一次。
然后,你会发现网站能正常工作了
我希望你看懂了我想要描述的一个问题:当网站的应用程序池帐号密码被修改之后,将如何影响到当前的网站。
先将结论给大家说一下
1. 如果当前的网站,没有被重置。我测试下来是,只要IIS没有被重启过,或者应用程序池没有被停止过,就可以继续使用。
2. 否则,当前网站会无法正常工作,而且应用程序池再也无法启动,除非设置正确的密码。
那么,这是为什么呢?
1. IIS启动的时候,默认会启动所有的应用程序池,并且使用它们的标识和密码,去请求windows系统(可能是本机,也可能是AD)进行认证
2. 只要认证通过了,那么应用程序池将启动,而且这个身份会被缓存起来。
3. 一般的应用程序,要访问后台数据库的时候,如果选择了“集成验证(integrated security=true)”这种方式的话,那么就是使用应用程序池的这个身份。
4. “集成验证”有时候也称为信任连接,这是什么意思呢?就是说SQL Server其实不再对帐号和密码进行验证,它“信任”windows传递过来的身份,也就是说,只要上面的第2步通过了,确实帐号是app_pool_test,那么SQL Server就认为它是app_pool_test,而不再重复验证密码。
5. 当IIS被重启,或者应用程序池被重启,此时就需要再次验证身份。而如果此时发现密码不匹配了,就自然无法启动应用程序池,然后也自然无法启动网站,然后也不会发生访问数据库的行为。
总结
在做应用程序部署的时候,你会遇到很多复杂甚至棘手的情况,这篇文章就描述了其中一种常见的状况:
应用程序池的帐号密码修改之后(其实,很多时候,作为开发人员的角度,你可能不知道密码已经被修改了),所以你可能会发现一些“诡异”的现象,例如刚刚还能正常使用的程序,突然又不能使用了。理解本文,将有助于你解释这样的状况,以及了解如何解决。