来源: 互联网  发布时间: 2013-12-24

1）首先新建一个应用程序池，名称任意，比如：nettest，托管管道模式先暂时设置为集成模式，等下面的一系列设置完成之后再设置成经典模式；
2）部署好站点，并将此站点的应用程序池设置为nettest;
3）选中站点，切换到功能试图，找到 "服务器组件"-> "处理程序映射"，双击之后，在打开窗口右侧的操作栏目下做如下设置：
4）"添加脚本映射"：请求路径 .html ，可执行文件选择 C:\Windows\Microsoft.NET\Framework\v2.0.50727\aspnet_isapi.dll ，如果是4.0，则为C:\Windows\Microsoft.NET\Framework\v4.0.30319\aspnet_isapi.dll，名称随意；
5）"添加通配符脚本映射"：请求路径 * ，可执行文件为：C:\Windows\Microsoft.NET\Framework\v2.0.50727\aspnet_isapi.dll，名称随意；
6）"添加托管处理程序"：请求路径 * ，可执行文件：System.Web.UI.PageHandlerFactory，名称随意；
7）打开站点切换到功能试图，找到 "服务器组件"->"模块"，双击之后，在打开窗口右侧的操作栏目中，点击"添加托管模块"，类型
URLRewriter.ModuleRewriter，并且把"仅针对向asp.net 应用程序或托管处理程序发出请求调用" 选中；
8）最后，找到我们第一步建立的应用程序池nettest，将托管管道模式设置为经典模式。
以上完成之后，即可实现IIS 7.5下的伪静态操作。

IIS7.5 伪静态 web.config 配置错误

在本地测试一个用伪静态写的网站，伪静态的配置是IIS7 伪静态 web.config按照这种方法来配置了。但是访问网站的时候提示 配置错误。我把网站的web.config rewrite 节点删除以后 网站可以访问，但是 不支持伪静态了。百思不得其解，这种方法就是针对IIS7 版本来做的啊？并且这个网站上传到我的IIS7的服务器是没有问题的，所以 就在想是不是 IIS7.5 的某些插件是不是没有按照。最后 通过途径 找到了原因，是因为我的IIS7.5没有安装URL Rewrite。先给大家发下下载地址 在本地安装以后 关掉IIS，重新打开即可。然后网站加入rewrite节点部分的代码网站也正常了。
下载地址：http://www.iis.net/download/URLRewrite

Windows7 IIS7.5本地测试伪静态(Rewrite)

自从换了空间以后，还是学习了不少新的东西，风云互联的主机支持一些别的空间不支持的组件，以前空间不支持ASPJPEG，不支持伪静态(Rewrite)，现在新空间都支持。

　　伪静态是个很好的东西，用处是非常大的，这点我就不用多讲了，论坛上讨论伪静态的很多，其实伪静态也不是什么神秘的东西，知道一些规则，用起来还是很方便的，关于规则的书写，网上有很多，大家可以研究研究。

　　以前因为测试环境的影响，一般都不是在本地测试的，都是放到真实的网站空间里调试的，这也给调试带来点小麻烦，上传下载的，有点浪费时间了，于是想在本地研究研究伪静态。

　　关于Windows 7下IIS7.5的伪静态的介绍好像很少，一般都是Vista下的IIS7.0，不过好在IIS7.0和IIS7.5差别并不是很大，不过对于我这个直接从IIS5.1跳到IIS7.5的人来说还是有点小麻烦的，从5.1到7.5变化还是蛮大的。

　　下面说下IIS7.5下伪静态(Rewrite)的安装，安装很傻瓜式的，下载这个组件，下载好了直接安装下就可以了。我是在IIS官网上下载的，我下的1.1版的现在2.0RC版已经出来了，不过为了稳定起见，我还是用的1.1，下载地址：http://www.iis.net/expand/URLRewrite

　　安装好了之后我们打开IIS，即可在网站IIS的配置中看到 URL rewrite的选项

　　双击URL rewrite图标(前提是先选定左边“网站”目录下你想使用伪静态的那个本地测试网站目录，如图)，然后我们就进入到了rewrite管理页面；

　　然后我们就进入到了rewrite规则管理页面；

　　点击Add Rules后我们即可进入添加规则页面，当然最简单的处理方式就是在本地写好一个 *.htaccess 规则文件，然后点击Import Rules导入就OK了。

　　不过本地测试的rewrite规则和上传到空间里面的不一样，举个简单的例子，我在本地用的规制是RewriteRule coolsite.html LoadMod.asp?plugins=CoolSite而在真实空间使用RewriteRule coolsite.html LoadMod\.asp\?plugins=CoolSite才可以，有些我用到正则匹配写的规则也是本地与真实上传到空间的不一样，而且相对路径绝对路径的问题也让我摸索了一会儿，不知道是我写的规则有局限性还是原本就是这样，希望有高手能给我解答下。

　　没有在主博客里面测试，用的是我的测试博客调试的。

    

    来源: 互联网  发布时间: 2013-12-24

我们的网站中往往包含大量的页面组件，比如图片、样式表文件、JS脚本文件和Flash动画。这些组件的变化频率非常低，尤其是那些构成网站基本框架的组件，

几乎不会发生变化。我们可以将这些变化率很低的组件看作静态内容，利用IIS的内容过期机制和浏览器的本地缓存机制将它们在访问者的电脑硬盘中保存一段时间。

当访问者访问你的网站时，如果这些存在本地的静态内容没有过期，浏览器会从本地硬盘中装载，而不去向服务器发出请求。

如果你使用Fiddler这样的工具跟踪网页访问，你会清楚地看到虽然只是访问一个页面，但是发出的Http请求和应答却不止一个。网页中的每张图片，每个

JS脚本文件，每个CSS文件，都会引发一次请求和应答。因此如果想让网页的访问速度快起来，减少Http的请求数量，降低从服务器下载内容的次数是有效途径。

而使用了内容过期机制后可以就实现这样的目的，这就是使用内容过期机制的意义。

大多数的Web开发者都玩过IIS 6或IIS 7，但是又有多少人仔细观察过HTTP Headers或HTTP Response Headers标签中的内容呢？此处我以IIS 6 为例，

默认情况下此标签中的界面如下图：

此时，如果向该网站的一个网页发出请求，该网页中包含了一张图片的链接，那么在获取到该网页的HTML文档之后，浏览器会继续对这张图片发出请求，该请求的响应在Http Response Header中如下表达：

HTTP/1.1 200 ok （表示服务器找到了此图片并正确响应）

Date:Thu, 04 Feb 2010 08:25:38 GMT （响应的时间，格林尼治时间）

Last-Modified:Wed, 03 Jan 2009 01:55:06 GMT（图片最后被修改的时间，格林尼治时间）

这张图片会被浏览器保存在本地硬盘的IE临时文件夹中。使用同一个浏览器窗口在同一个会话中再次访问到这个页面，
则页面中的组件都不再重新请求。

当在这台机器上打开另一个浏览器窗口（另一个会话）又一次访问此页面时，由于这张图已经在本地保存了，但是浏览器
刚才的响应中并没有规定内容的过期机制，因此浏览器仍会向服务器发出一次请求：
If-Modified-Since: Wed, 03 Jan 2009 01:55:06 GMT （询问服务器，我本地这张图片的最后修改时间是这个，在此时间之后你那有没有更新的版本？）
If-None-Matched: "abdkfkdkdkdjkjkfkfd" （这是一段ETag编码，是服务器端给该组件的唯一标示）

服务器收到请求后检查被请求的图片，发现它的最近修改时间还是Wed, 03 Jan 2009 01:55:06 GMT ，于是响应请求：
HTTP/1.1 304 Not Modified （请求的图片找到了，并且没有被改变过）

Date:Thu, 04 Feb 2010 08:25:38 GMT （响应的时间）
浏览器收到这个响应就知道它可以放心地使用本地存储的这张图片了，不必再从服务器重新下载该组件。

由此可见，IIS Http Headers标签的默认设置是不禁止浏览器缓存的，但是也没有告诉组件保存过期的时间，因此浏览器将组件保存在本地后，
每次访问都会询问服务器此组件是否过期，如果没过期则使用本地保存的内容，否则从服务器下载内容。 可以看出它只减少了从服务器下载内容的次数，
并没有减少向服务器发出请求的次数，请求和响应依然耗费了时间。

在IIS中定位到网站存放图片的文件夹，然后打开属性窗口，在HTTP Headers中做出如下选择，要求组件的过期时间为本次请求后1天，也就是在本地缓存86400秒。

打开浏览器，首次访问该网站的一个网页，该网页中包含一张图片的链接，于是该图片请求的响应在Http Response Header中如下表达：

HTTP/1.1 200 OK （表示服务器找到了此图片并正确响应）
Cache-Control: max-age=86400 （从本次请求时间算起，允许该图片在本地缓存86400秒）

Date: Sat, 14 May 2011 08:09:29 GMT （响应的时间，格林尼治时间）
于是，只要是在1天之内，使用本机的浏览器打开这个网页，都不会再对这张图片发出请求，而是直接使用本地缓存中的这张图片。可见，减少了不必要的HTTP请求，

提高了网页的响应速度。

很多网站框架性的组件都是长期不变的，因此我们可以设置更长的过期时间，如下所示：

打开浏览器，首次访问该网站的一个网页，该网页中包含一张图片的链接，于是该图片请求的响应在Http Response Header中如下表达：
HTTP/1.1 200 OK （表示服务器找到了此图片并正确响应）
Date: Sat, 14 May 2011 08:50:12 GMT（响应的时间，格林尼治时间）
Expires: Mon, 23 May 2011 16:00:00 GMT (该图片的本地缓存到2011年5月23日16点为止，格林尼治时间)
那么这意味着只要在5月23日16点之前，在本机上访问该网页，都不会再对此图片发出请求。

有人担心如果这样设置过期机制，一旦对这些组件做了更新，访问者将不能收到变化，那岂不是也很遗憾。其实这有两方面的解决方式：
一方面是网站的开发方，应该对图片，样式表文件和JS文件的命名方式进行改进，比如在文件名上加入版本号，这样你一旦修改了组件内容，
就应该使组件拥有新的名称，于是浏览器会发现本地没有对这个组件缓存过，自然就会发起请求。
另一方面，访问者可以通过浏览器的刷新功能强制对网页中的组件重新发起请求。即使设置了过期机制，浏览器的刷新功能仍然会对所有页面组件
发出请求的。

总结，本文的目的就是阐释浏览器本地缓存与Web服务器缓存过期机制之间的交互关系，以及如何通过这种方式达到对性能的提升。
根据《高性能网站建设指南》一书中的统计，从浏览器向一个网页发出请求算起，获得网页的HTML文档的时间只占整个页面应答完成时间的
5%，而剩余的95%时间全部是在请求和下载页面中的各个组件。因此减少对页面中组件的请求和下载，有效地利用浏览器缓存机制是十分有意义的。

    

    来源: 互联网  发布时间: 2013-12-24

ASP连接数据库的连接字符串是Provider=Microsoft.Jet.OLEDB.4.0; Data Source=路径，采用的是OleDB方式连接，问题可能就出在OleDB方式连接这一环节上。

后来搜索网络得到了解决的办法 。原来是自己装的64位Windows 7系统的原因，默认64位环境下，IIS应用程序池未启用32位应用程序，我们只需要启用一下就可以了。打开IIS 7，定位到“应用程序池”，然后选择使用OleDB方式连接数据库的程序池，然后将启用32位应用程序设置为True就可以了。



Using MyODBC with ASP.NET in IIS7 on Vista x64

That's a heck of a title, but it's a problem I hit recently. I have a bunch of ASP.NET sites that use MySQL as their datastore, but I hadn't tried the on IIS7 yet. It took a while to get them to work at all (I had to set permissions on web.config and the other website files so that they could be read by both the Users group and the IIS_IUSRS group), but then I was left with an error about my MySQL connection. “ERROR [IM002] [Microsoft][ODBC Driver Manager] Data source name not found and no default driver specified” – another very general error that basically means “Something is wrong with your ODBC driver, somewhere.”

After some searching, I learned two things. The first is that if you're running 64-bit you can't use the standard ODBC Data Source Administrator in Administrative Tools with MySQL. You've got to go to C:\Windows\SysWOW64\odbcad32.exe and set up your DSN, if that's your thing. The other thing is that the MyODBC driver is 32-bit only. So to use it at all, you need to make sure you're calling it from 32-bit apps only. That means you've got to tweak the Application Pool you're using to run all its ASP.NET applications as 32-bit. To do this, go to Administrative Tools > Internet Information Services (IIS) Manager (or just hit the Windows key and type “IIS”). Then go to “Application Pools” and select whichever application pool your ASP.NET app uses (or create a new one just for your MySQL apps. Click “Advanced Settings…” and set “Enable 32-Bit Applications”. Now the AppPool will use the 32-bit .NET CLR to run your app, and it'll be able to see your MyODBC driver (whether you use a DSN or not).