Wishlist 0 ¥0.00

IIS7 Output Caching for Dynamic Content - Speed Up Your ASP and PHP Applications

IIS7 has a new output cache feature that can cache dynamic content (output from your ASP.NET, Classic ASP, PHP or other dynamic pages) in memory.  This can yield enormous performance improvements since it means that the script used to generate that dynamic output doesn't need to run for each request.  The cache is "smart" enough to vary the output cached based on query string values as well as HTTP headers sent from the client to the server.  The cache is also integrated with the http.sys kernel mode driver, enabling blazing fast performance.

 

When to use it

IIS automatically caches static content (like HTML pages, images, and style sheets) for you, since these types of content don't change from request to request.  IIS also detects changes to the files when you make updates, and flushes the cache as needed.

The output from dynamic pages can now be cached in memory as well.  Not every dynamic page can take advantage of the output cache.  Pages that are highly personalized (like shopping cart / e-commerce transactions) are not good candidates because the dynamic output isn't likely to be requested again and again, and the memory used to cache the content would be wasted.  Content that is output as a result of a POST type request to an HTML form is also not cacheable.

Good candidates for the output cache are pages which are semi-dynamic in nature meaning the data is generated dynamically, but isn't likely to change from request to request based on the URL or the header information.  For example, photo gallery type applications that dynamically resize images for display in a web page are great candidates for the output cache because caching the data saves the server from having to re-process the image resizing for each request.  You can read more about this scenario, and how I used the output cache to get more than an order of magnitude greater performance with a PHP photo gallery application here.  Another good example of a type of application that can take advantage of the output cache feature is a stock ticker application.  Let's use it to walk through how such an application can take advantage of the output cache:

Varying the cache

Let's assume for this example that I have an application that allows the user to input a stock symbol which submits the symbol the my application as such:  http://server/showStockPrice.asp?symbol=MSFT

In this case, the URL is always http://server/showStockPrice.asp, but the querystring value (symbol=MSFT) tells the showStockPrice.asp page which data to include in the response, therby varying the output of the page by querystring value.  This is called varyByQuerystring in output cache lingo.  IIS also supports another type of cache policy: varybyHeaders which can vary the cache based on the HTTP headers that are sent from the client to the server.

Caching the output of this data is useful, because it is likely that many people may in fact by requesting the stock price for "hot" stocks ( like MSFT! :) ), and by caching it I save the server from having to lookup the current stock price for a particular symbol for each request. 

Invalidating the cache

Since we're caching dynamic data, there is a good chance it is going to change and we will need to flush the cache, allowing new data to be retrieved and re-cached.  In this example, the stock price is likely to change frequently.  Even in the case where the stock price is changing every second, it may be useful to cache the data if the site is getting hundreds of requests per second.  That could mean one trip to the database to retrieve the stock price, instead of a hundred every second, saving the Web server and the database server from extra work.

IIS supports two types of invalidation schemes for dynamic content.  The first is a simple timeout period.  The configuration property for this is CacheForTimePeriod.  The other way to invalidate the cache is for IIS to detect a change to the underlying resource.  The configuration property for this CacheUntilChange.  Use this type of invalidation scheme only when you want the cache flushed when the underlying resource (in this case showStockPrice.asp) changes. 

Configuring the cache

The cache is pretty easy to configure, and comes with a fancy UI feature in the new IIS admin tool to configure it (beta 3+ only). 

 

You can also configure the feature in your local web.config file that lives in the content directory.  Here is a sample of the configuration needed for our showStockPrice.asp page, with a varyByQueryString parameter of * (meaning cache all unique variations of querystring parameters) and a timeout of 1 second.

<configuration>
     <location path="showStockPrice.asp">
       <system.webserver>	
         <caching>
           <profiles>
             <add varybyquerystring="*"location="Any"
               duration="00:00:01" policy="CacheForTimePeriod"
               extension=".asp">
           </profiles>
	</caching>
       </system.webserver>
   </location>
</configuration>

If I want to cache this data in kernel for every faster performance, all I need to do is change the "policy" attribute to kernelCachePolicy.  Note: there are a few limitations you should be aware of with the kernel mode cache, read more about them below.

 

More Information

ThomaD recently published a more extensive article on output caching, located here:  http://learn.iis.net/page.aspx/154/iis-7-output-caching/  It will walk you through an end to end example of using the output cache, and provide troubleshooting tips and much more information on how to use this powerful new IIS7 feature.

Note: ASP.NET already has an 'output cache' feature that is very closely integrated with ASP.NET.  This IIS output cache feature works in parallel with that one, and works for all types of applications.

2 Comments

  • Really useful article! we've been doing a lot of investigation into caching performance internally so this info comes at a really good point ! Time to go install longhorn and test it with our sites ! :P

    (Also I was trying to paste this to friends to read but the formatting seems to have freaked out slighly and some words are not visible on the right (IE7) - i read this originally via RSS)

    Stephen Pope -
  • Querystring values as well as headers? Interesting. That could be a great option for many dynamic pages, regardless of language. Others, however, obviously could vary their response by additional factors such as cookie values.

    Along the lines of caching, what would be interesting to see would be taking the concept of a dynamic 'page' and turning it into a dynamic ‘process’ that could be set to run and stay active until a sleep time is reached, but this process could have resources already loaded and ready, therefore potentially increasing response time. In other words a process that stays awake and listens for repeated requests and is ready to serve them, rather than several different threads or processes opening up, loading resources, processing a request and then quitting, only to restart again. I dare say it might be possible that in some rare cases the CPU cycles required to load the darn page are more than to process the actual request!

    Come to think of it, I might need to brush up on my ASP.NET, as it may already do that or something similar…

    Will Smith -

IIS的应用程序池优化方法

服务器经常产生“应用程序池 'DefaultAppPool' 提供服务的进程关闭时间超过了限制。进程 ID 是 '3504'。”的错误,导致iis处于假死状态,经了解是IIS应用程序池的设置问题。解决方法如下(红色字为标记)

Internet 信息服务(IIS)管理器->应用程序池->DefaultAppPool->右击属性
一、回收
1、回收工作进程(分钟):选中,值为1740 (800)
2、回收工作进程(请求数目):(不选)(原先设置为35000)
3、在下列时间回收工作进程:不填 (03:00)
4、消耗太多内存时回收工作进程:全不选。(2、3、4项可能避免了在访问量高的时候强制回收进程可能引发的服务器响应问题,导致iis假死不响应)(最大虚拟内存350,最大使用的内存200)
二、性能 (都不选)
只选中空闲超时20分钟。其他都不选。WEB园最大工作进程数为1(默认)。注意web园这里一定要保持默认,如果填写其他超过1的数字就会导致一些网站程序的后台程序打不开或者刷新不停。

原来的请求队列限制为4000,现在无限制。(要选就是10000)
三、运行状况
(启用PING,默认)

(启动快速失败保护的钩去掉!)
为了避免真的遇到很多错误时没有提示,可以不关闭,只是把快速保护的保护范围加大些,例如失败数50次 时间段5分钟 则关闭对应的程序。

(启动时间限制90秒,关闭时间限制180秒。)
“关闭时间限制180秒”是必须的,因为进程关闭的时间,原来为90秒限制,是默认值,如果进程关闭时间超过90秒,则认为超时,从而出现:进程关闭时间超过了限制 日志,所以,适当延长这个时间,可以避免这种错误!
 

IIS6.0应用程序池回收和工作进程

公司的一个网站程序长时间运行后,速度变慢,重新启动网站后速度明显变快,估计是网站程序占用的内存和CPU资源没能及时释放,才需要每隔一段时间重启网站释放资源。但手工重启总不能算解决问题的方法,怎样才能实现自动管理呢?IIS6.0的应用程序池自动回收功能可以解决这一问题。

应用程序池是将一个或多个应用程序链接到一个或多个工作进程集合的配置。因为应用程序池中的应用程序与其他应用程序被工作进程边界分隔,所以某个应用程序池中的应用程序不会受到其他应用程序池中应用程序所产生的问题的影响。

为Web程序配置应用程序池需要以下步骤:1)创建应用程序池,右键单击“应用程序池”,“新建/应用程序池”,命名为KefuAppPool;2)为Web程序指定应用程序池,在网站虚拟目录属性“应用程序设置”里面的“应用程序池(N)”里选择KefuAppPool;3)应用程序池自动回收方式的设置。回收方式有如下几种:

a.根据运行时间

系统默认是1740分钟,也就是29个小时,这个不是很好控制,建议不用。

b.请求数目

这个要看具体的情况了。如果只有10个请求,可是有5个都在请求那个比较占资源的页面(可能是统计年度报表之类),这个时候就会出现进程当掉的情况,如果请求有1000个可是一个也没运行比较占资源的页面,这个时候进程肯定是很正常的,所以根据请求的数目来决定也不一定符合实际需要。

c.计划的时间

这个其实很好,不过具体什么时间回收好呢?通常我们都是设置在凌晨两三点钟,这个时候回收是有必要的,不过针对出现随时可能出现是高内存占用并不是很适用。

d.内存(虚拟内存或已使用的内存)

这个针对出现内存问题引起的进程当掉实在太合适了,不过设置多大的值比较好是一个很重要的问题,值不能太小了,否则如果访问量都很大超过这个值的时候也会自动回收,这个就很没必要了。一定要多多观察进程的实际占用情况再做决定。

下面重点谈谈对工作进程回收应用程序池的理解。

默认情况下,WWW服务建立“重叠回收”,即继续运行要终止的工作进程,直到启动新的工作进程后为止。 在重叠回收方案中,要回收的进程继续处理请求,同时 WWW 服务创建一个替代工作进程。在停止旧工作进程之前启动新的工作进程,然后将请求定向到新的进程。此设计可以防止服务中断,因为旧进程关闭前仍然保持与 HTTP.sys 的通信以处理请求。因为可重叠关闭或启动的关闭超时值是可以配置的,所以在工作进程仍在处理请求的同时可以终止该进程(如果它在时间限制内没有处理完请求的话)。

注意:当 WWW 服务回收某个工作进程时,它并不断开现有的 TCP/IP 连接。HTTP 协议堆栈 (HTTP.sys) 建立并维护 TCP/IP 连接。

IIS中的每个应用程序池由一个“工作进程”进行管理,也就是"W3wp.exe" 进程。如果有多个应用程序池中的程序运行,我们就能看到多个w3wp.exe。这点可以在任务管理器中看到,如下图所示,任务管理器中有两个w3wp.exe进程,恰好对应两个有应用程序在运行的应用程序池。

在命令提示符下运行iisapp -a,可以查看w3wp.exe和哪个应用程序池关联。

下图显示了手动执行应用程序池KefuAppPool的回收,在回收前,回收中和回收后应用程序池和工作进程情况。我们注意到:回收过程中增加了一个工作进程(PID=3896),该工作进程(PID=3896)启动好后,旧的工作进程(PID=5716)才被停止,新工作进程(PID=3896)正式替代旧进程工作,这就很好的防止了应用程序池回收过程中服务被中断,保证了程序的连续运行。而其他两个应用程序池对应的工作进程 PID都没用变。该图很好的展示了应用程序池回收的过程。

 

 

应用程序池这个东西着实让管理服务器的人头疼,如果不设置好网站随时有可能罢工,甚至拖累服务器。因此特地找来此文章供大家参考。

另外说一点,如果网站访问量不是很大,晚上没什么人访问,可以尝试凌晨重启服务器,这样可以提高服务器的速度,为第二天的访问做准备。
 

IIS 6的核心在于工作进程隔离模式,而应用程序池则是定义工作进程如何进行工作,因此,可以说应用程序池是整个IIS 6的核心。

和IIS 5中只能使用单个应用程序池不同,工作在工作进程隔离模式的IIS 6可以创建多个应用程序池,不同的应用程序池之间是完全隔离的,某个应用程序池停止服务时不会影响到其他应用程序池。

在使用应用程序池之前,你应该确定你所需要的应用程序池数量。可能有很多朋友会认为,既然不同的应用程序池之间是完全隔离的,那么我只需要为每个Web站点创建一个应用程序池就可以了。这个办法在IIS服务器上具有较少的Web站点数量时可以使用,但是如果IIS服务器上具有很多Web站点数量,那么这个办法就不适用了,因为不同的应用程序池在被访问时都会创建各自的工作进程,当大量的工作进程并发工作时会消耗大量的系统资源和CPU利用率,反而会降低服务器性能。你应该根据Web站点的重要性、隔离性、所运行代码的安全性和稳定性等来对IIS服务器上所具有的Web站点进行划分,然后根据情况来决定所需要的应用程序池数量。对于那些非常重要的Web站点、需要单独隔离的Web站点、所运行代码稳定性和安全性并不可靠的Web站点配置为使用各自独立的应用程序池,而将其他普通的Web站点配置为使用一个公共的应用程序池。

默认情况下,在安装IIS时会创建一个默认网站并创建一个名为DefaultAppPool的应用程序池为其使用;默认配置下的应用程序池已经可以很好的进行工作,建议你只有在特别需要时才对应用程序池进行配置。

配置应用程序池属性

在IIS管理控制台中展开应用程序池文件夹,然后右击对应的应用程序池,点击属性,你可以在应用程序池的属性中进行以下配置:

回收

在回收标签,你可以设置工作进程的回收方式:

 

 

回收工作进程(分钟):在工作进程运行多少分钟后回收工作进程,默认启用,并且设置为1740分钟(29小时);

回收工作进程(请求数目):在工作进程处理多少 个HTTP请求后终止此工作进程,默认禁用,如果启用则默认值为35000;

在下列时间回收工作进程:在指定的时间回收工作进程,默认禁用;如需启用,勾选后点击添加按钮添加回收的时间即可,使用24小时制定义回收的时间;

消耗太多内存时回收工作进程:

最大虚拟内存(兆):当工作进程使用的虚拟内存达到设置的值时回收工作进程,默认禁用,如果启用则默认值为500 M;建议设置为不超过虚拟内存总数的70%;

最大使用的内存(兆):当工作进程使用的物理内存达到设置的值时回收工作进程,默认禁用,如果启用则默认值为192 M;建议设置为不超过物理内存总数的60%;

另外需要注意的是,应用程序池具有以下两种工作进程回收方式,不过这两种回收方式均不会造成Web服务的中断:

默认情况下,应用程序池使用重叠回收方式。在这种方式下,当应用程序池要关闭某个工作进程时,会先创建一个工作进程,直到新的工作进程成功创建后才关闭旧的工作进程;

应用程序池也可以先关闭旧的工作进程,然后再创建新的工作进程。

如果Web 应用程序不支持多实例运行,那么你必须配置应用程序池禁止使用重叠回收方式。此配置无法在IIS管理控制台中进行修改,只能通过在 metabase.xml中修改对应应用程序池的DisallowOverlappingRotation metabase属性为true进行。

 

性能

在性能标签你可以设置工作进程的运行方式:

 

 

在空闲此段时间后关闭工作进程(分钟):当工作进程空闲多少分钟后关闭此工作进程,这降低了空闲工作进程对系统资源和CPU性能的消耗,默认启用并且设置为20分钟;

核心请求队列限制为(请求次数):当HTTP.sys接收到某个客户端发送的HTTP请求时,如果处理此请求的对应应用程序池的工作进程还处于忙状态,则HTTP.sys将接收到的请求保存在对应应用程序池的请求队列中,直到工作进程空闲为止。此选项即用于设置此应用程序池的请求队列所能容纳的请求数量,默认情况下每个应用程序池的请求队列限制为保留1000个请求,如果超出则向客户端返回503错误,你可以根据需要适当进行修改,最大可以设置为65535。但是如果设置太大则会消耗大量的系统资源 ,而设置太小会导致客户端访问时频繁出现503错误。

启用CPU监视:监视此应用程序池的CPU使用率,默认未启用;如果某个应用程序池占用的CPU利用率过多,那么可以通过配置此选项来限制此应用程序池;

最大CPU使用率(百分比):所设置的应用程序池所能使用的最大CPU使用率;启用CPU监视时默认值为100;

刷新CPU使用率(分钟):刷新CPU使用率的间隔时间;启用CPU监视时默认值为5;

CPU使用率超过最大使用率时执行的操作:当此应用程序池的CPU使用率超过所设置的最大CPU使用率时所进行的操作,启用CPU监视时默认为无,此时IIS只是在事件日志中进行记录而不进行其他操作;如果选择为关闭,那么IIS将关闭此应用程序池中的所有工作进程;

Web园:在Web园中你可以配置此应用程序池所使用的最大工作进程数,默认为1,最大可以设置为4000000; 配置使用多个工作进程可以提高该应用程序池处理请求的性能,但是在设置为使用多个工作进程之前,请考虑以下两点:

每一个工作进程都会消耗系统资源和CPU占用率;太多的工作进程会导致系统资源和CPU利用率的急剧消耗;

每一个工作进程都具有自己的状态数据,如果Web应用程序依赖于工作进程保存状态数据,那么可能不支持使用多个工作进程。

运行状况

在运行状况标签你可以配置应用程序池监视工作进程的运行状况,

 

 

启用Ping:默认情况下应用程序池配置为每隔30秒Ping工作进程,当工作进程没有进行响应时,则认为此工作进程出现故障并默认配置为关闭此工作进程。你可以修改Ping的时间间隔,但是太长的Ping间隔可能会导致Web服务的中断,而太短的Ping间隔又会消耗更多的系统资源和CPU利用率,因此建议你保留默认配置;

启用快速失败保护:如果Web应用程序代码编写有问题,它可能会导致工作进程持续出现问题。默认情况下应用程序池配置为启用快速失败保护,当工作进程在配置的时间段(默认为5分钟)内发生的失败次数超过了配置的值(默认为5次),则禁用此应用程序池。

启动时间限制:IIS等待属于此应用程序池的工作进程启动的时间,当工作进程启用时间超出此设置值时,IIS会在事件日志中进行记录;

关闭时间限制:当IIS检测到某个工作进程出现故障时,将此工作进程标记为关闭,此选项指定了IIS等待工作进程自动关闭的时间限制,如果超出此时间限制后工作进程尚未关闭,则IIS强行关闭工作进程。

标识

在标识标签,你可以配置工作进程所运行的用户账户。在IIS 5或者当IIS 6运行在IIS 5隔离模式时,工作进程运行在本地系统账户,而运行在工作进程隔离模式下的IIS 6的工作进程运行在网络服务账户下,这降低了系统被攻击的可能性。

你可以配置工作进程运行在预定义的本地系统、本地服务或网络服务账户下,也可以配置为使用某个自定义的用户账户。建议使用默认的网络服务账户;不过如果为了更高的安全性,可以配置使用自定义的用户账户,不过建议你只是将此自定义用户加入到IIS_WPG用户组中,因此IIS_WPG用户组包含了可以启动和运行工作进程的最小权限。

 

 

1)在任务管理器中增加显示pid字段;2)在命令提示符下运行iisapp -a。注意,第一次运行,会提示没有js支持,点击确定。然后再次运行就可以了。这样就可以看到pid对应的应用程序池。如上图左侧所示,应用程序池 KefuAppPool和PID=3232的w3wp.exe相关联,应用程序池ReportServer和PID=3572的w3wp.exe相关联。

IIS输出缓存设置的坑

以前没有使用过网站IIS 输出缓存的设置。这次由于某个维护的网站挪服务器了。就想试试效果。于是添加了2条规则。一个是.aspx的,一个是.asp的。设置如下:

感觉这样设置挺好。文件修改才通知,不修改就不通知,挺好。没毛病。

但是现实是残酷的,过了2天,更新网站内容的人却通知我说,后台翻页不能用了,只能翻两页,再往后翻就翻不动了。我刚开始不明白他的意思。这晚上自己查看,才明白他说的意思。这翻到第三页,第四页,页面内容和第二页一直是相同。想了想这段服务器挪过来后设置也就变了一次。就是在IIS 上设置了一个输出缓存,感觉坏了,是不是这里出问题了。把这两条设置的规则删除,再查看,翻页正常了。

分析原因,推测因为asp页面中的代码一直没变,因此服务器一直没通知客户端浏览器。而虽然翻页有页码,但是显然客户端不会因为你url 带参数就认为你页面内容改变,导致的一直输出是原来的内容。看来这输出缓存使用还是有条件的,静态的htm 这类文件以及图片可以用。动态网页是不适用的。

IIS设置输出缓存和压缩

概要:

 记录一下给发布后的网站设置输出缓存和压缩。

步骤一:启动IIS
这里写图片描述

步骤二:选择任意一个网站
这里写图片描述

步骤三:双击输出缓存
这里写图片描述

步骤四:在空白页右键添加,配置需要缓存的文件和缓存时间间隔
这里写图片描述

步骤五:回到网站实例页
这里写图片描述

步骤六:点击压缩
这里写图片描述

 

About Us

Since 1996, our company has been focusing on domain name registration, web hosting, server hosting, website construction, e-commerce and other Internet services, and constantly practicing the concept of "providing enterprise-level solutions and providing personalized service support". As a Dell Authorized Solution Provider, we also provide hardware product solutions associated with the company's services.
 

Contact Us

Address: No. 2, Jingwu Road, Zhengzhou City, Henan Province

Phone: 0086-371-63520088 

QQ:76257322

Website: 800188.com

E-mail: This email address is being protected from spambots. You need JavaScript enabled to view it.