Re: IIS 6.0 Not Caching Images
From: David Wang [Msft] (someone_at_online.microsoft.com)
Date: 08/05/04
- Next message: MikeL: "IIS 6 Application Crashing"
- Previous message: Me: "Re: IIS replacing blanks"
- In reply to: Joe Rattz: "Re: IIS 6.0 Not Caching Images"
- Messages sorted by: [ date ] [ thread ]
Date: Thu, 5 Aug 2004 15:37:54 -0700
The handler that sent /GPCStoreFront/Images/watermark.gif will need to send
an ETag header, which the client would reuse on subsequent requests to the
same resource for a 304 optimization.
So, I'm thinking:
1. IE is not sending ETag header on the request correctly. Highly unlikely
because the same browser code causes 304 to return from IIS5
2. IIS is not sending the ETag header on the request correctly. Highly
unlikely because I can cause the 304 to return
3. Something else is configured to handle .gif , and it does not send back
an ETag header (so browser cannot use 304 optimization). Possible.
I would do a network trace (Windows Server 2003 comes with Network Monitor
to do this) to look at the exact request/response being sent to make sure
that 304-logic is in action and clarify between the three possibilities.
-- //David IIS This posting is provided "AS IS" with no warranties, and confers no rights. // "Joe Rattz" <joerattz@yahoo.com> wrote in message news:OY6Ux4ueEHA.2916@TK2MSFTNGP12.phx.gbl... Based on what I see in the log (many 200's for the same URL/image), I must be seeing #2. > 2. /GPCStoreFront/Images/watermark.gif is not requested with the right > "If-None-Match: <ETag>" header so IIS responds with 200, and it could be > coming out of the kernel mode cache or not. But, I don't know what you are talking about with this. This is an ASP.NET web form with an image. What is determining the header for it? "David Wang [Msft]" <someone@online.microsoft.com> wrote in message news:u84%23T0oeEHA.248@TK2MSFTNGP12.phx.gbl... > You're not exactly wrong, but you're making some assumptions that may not be > valid. > > In any case, I looked at this, and here is what is going on: > 1. There is a known bug where if a 204/304 is fulfilled from the kernel > response cache, HTTP.SYS won't log it > 2. If 204/304 is fulfilled by usermode, IIS will cause HTTP.SYS to log it > 3. However, the right HTTP communication is happening between client/server > in those cases -- if you send the right ETag, a 304 will be returned > regardless if it is fulfilled from the kernel response cache or not. > > I can show with #2 and #3 that IIS6 is caching images -- it's just the log > that is wrong in the kernel cache hit case. I do not think you're seeing #1, > though, because your log pattern does not suggest it. > > Finally, in order for you to track down what is going on, you need to know > when a request is fulfilled by the kernel mode response cache and when a > request is cached in kernel mode (in addition to using WFetch to make the > proper requests or use NetMon as proof). > 1. You will need to look at PerfMon for "Web Service Cache\Kernel cache: > Kernel URI Hits" for if a request is a kernel mode cache hit or not > 2. You will need to make three consecutive requests to the same static-file > URL within 10 seconds to make it cache in the kernel. Without programming, > you cannot evict an item from the cache, so "NET STOP HTTP /y & NET START > W3SVC" is the easiest way to flush the caches. > > > So, what I think is happening in your case is either: > 1. /GPCStoreFront/Images/watermark.gif is already cached in the kernel > response cache and returning 304s -- which aren't logged > 2. /GPCStoreFront/Images/watermark.gif is not requested with the right > "If-None-Match: <ETag>" header so IIS responds with 200, and it could be > coming out of the kernel mode cache or not. > > If #1 was happening, then you would see only a couple log entries for > /GPCStoreFront/Images/watermark.gif and then no mention of this URL for a > very long time (until the entry expired from the kernel mode cache). > > If #2 was happening, then you will repeatedly see log entries for > /GPCStoreFront/Images/watermark.gif with 200 . It may be cached on the > server or not -- you need perfmon to determine. > > I think you are seeing #2. In any case, you should now have enough info to > determine for yourself what is going on. > > -- > //David > IIS > This posting is provided "AS IS" with no warranties, and confers no rights. > // > "Joe Rattz" <joerattz@yahoo.com> wrote in message > news:OtjB%23HieEHA.592@TK2MSFTNGP11.phx.gbl... > > A 304 "Not Modified" does NOT indicate that the server cached the > response. > > I am not referring to the server caching, I am referring to the client > browser caching. > > I would expect that when a client first requests an image, the status code > would be a 200 because the server has no way of knowing the client has it. > But, all subsequent requests for the same image I would expect to see 304 > for. > > Here is a sample from my log. These two records are 19 seconds apart and > are from the same session: > > 2004-08-04 12:41:03 10.28.98.130 GET /GPCStoreFront/Images/watermark.gif - > 80 - 10.28.11.180 > Mozilla/4.0+(compatible;+MSIE+6.0;+Windows+NT+5.0;+.NET+CLR+1.0.3705;+.NET+C > LR+1.1.4322) 200 0 64 > 2004-08-04 12:41:22 10.28.98.130 GET /GPCStoreFront/Images/watermark.gif - > 80 - 10.28.11.180 > Mozilla/4.0+(compatible;+MSIE+6.0;+Windows+NT+5.0;+.NET+CLR+1.0.3705;+.NET+C > LR+1.1.4322) 200 0 0 > > It seems to me that the second record's status should have been a 304, > thereby preventing the server from shipping the image data back the second > time. Am I wrong here? > > Thanks. > > > > > "David Wang [Msft]" <someone@online.microsoft.com> wrote in message > news:uwPfZwceEHA.556@tk2msftngp13.phx.gbl... > > I think you are mis-interpreting what is going on. The log file is not > the > > correct place to determine whether IIS is caching or not. You observe > > caching behavior by watching performance counters (perfmon) or empirically > > clocking request round-trip times over a large enough sample size. > > > > A 304 "Not Modified" does NOT indicate that the server cached the > response. > > It simply indicates that the client asked the server "I'm retrieving this > > URL, but I already have a copy of it with the following signature. If > this > > resource matches that signature, then don't send it again -- I already > have > > it. Otherwise, please give me the resource". > > > > Thus, a server answers 304 to such questions to tell the client "yup, > you've > > already got the resource. I'm not sending it to you again". Otherwise, > the > > server will return 200 with the updated resource as entity body. > > > > Clearly, a 304 (telling the client whether it already has the resource or > > not) is completely orthogonal to whether a response is cached or not. If > > IIS served out of the cache, you'd see a 200 response with no round-trip > to > > the slow hard drive. If it didn't serve out of the cache (but also sent > no > > entity body), then you'd see a 304. > > > > As for what is going on with IIS6 -- IIS6 caches some responses in kernel > > mode, and such cached responses are returned as 200 OK. Non-kernel-mode > > cached URLs still follow the 304 semantic and has its own user-mode based > > caching mechanism. > > > > Finally, it may be possible that you have caching disabled (many things > will > > disable many types of caching) -- but without looking at performance > > counters, it is not possible to confirm. > > > > -- > > //David > > IIS > > This posting is provided "AS IS" with no warranties, and confers no > rights. > > // > > "Joe Rattz" <joerattz@yahoo.com> wrote in message > > news:%23GV099WeEHA.1652@TK2MSFTNGP09.phx.gbl... > > I just noticed a difference between my development box running IIS 5.0 and > > my production server running IIS 6.0 that seems detrimental to > performance. > > In IIS 5, my images appear to be getting cached in that the server is > > returning an http status code (sc-status from the log) of 304. Here is a > > sample from the log: > > > > 14:15:32 127.0.0.1 GET /GPCStoreFront/Images/Collapse.gif 304 > > 14:15:32 127.0.0.1 GET /GPCStorefront/Images/questionmark.gif 304 > > 14:15:32 127.0.0.1 GET /GPCStoreFront/Images/Expand.gif 304 > > 14:15:32 127.0.0.1 GET /GPCStorefront/Images/newuser.gif 304 > > 14:15:32 127.0.0.1 GET /GPCStorefront/Images/addtofavorites.jpg 304 > > > > But, in IIS 6, I am getting 200 for images: > > > > 2004-08-03 15:26:53 10.28.98.130 GET /GPCStoreFront/Images/Collapse.gif - > > 80 - 10.28.11.180 > > > Mozilla/4.0+(compatible;+MSIE+6.0;+Windows+NT+5.0;+.NET+CLR+1.0.3705;+.NET+C > > LR+1.1.4322) 200 0 0 > > 2004-08-03 15:26:53 10.28.98.130 GET > > /GPCStoreFront/Images/questionmark.gif - 80 - 10.28.11.180 > > > Mozilla/4.0+(compatible;+MSIE+6.0;+Windows+NT+5.0;+.NET+CLR+1.0.3705;+.NET+C > > LR+1.1.4322) 200 0 0 > > 2004-08-03 15:26:53 10.28.98.130 GET /GPCStoreFront/Images/Expand.gif - > 80 - > > 10.28.11.180 > > > Mozilla/4.0+(compatible;+MSIE+6.0;+Windows+NT+5.0;+.NET+CLR+1.0.3705;+.NET+C > > LR+1.1.4322) 200 0 0 > > 2004-08-03 15:26:53 10.28.98.130 GET /GPCStorefront/Images/newuser.gif - > > 80 - 10.28.11.180 > > > Mozilla/4.0+(compatible;+MSIE+6.0;+Windows+NT+5.0;+.NET+CLR+1.0.3705;+.NET+C > > LR+1.1.4322) 200 0 0 > > 2004-08-03 15:26:53 10.28.98.130 GET > > /GPCStoreFront/Images/addtofavorites.jpg - 80 - 10.28.11.180 > > > Mozilla/4.0+(compatible;+MSIE+6.0;+Windows+NT+5.0;+.NET+CLR+1.0.3705;+.NET+C > > LR+1.1.4322) 200 0 0 > > 2004-08-03 15:26:53 10.28.98.130 GET /GPCStoreFront/GPCStoreFront.css - > 80 - > > 10.28.11.180 > > > Mozilla/4.0+(compatible;+MSIE+6.0;+Windows+NT+5.0;+.NET+CLR+1.0.3705;+.NET+C > > LR+1.1.4322) 200 0 0 > > > > CSS files are behaving the same way. > > > > Can someone tell me why my images (and CSS file) are not getting cached? > > > > Thanks. > > > > > > > > >
- Next message: MikeL: "IIS 6 Application Crashing"
- Previous message: Me: "Re: IIS replacing blanks"
- In reply to: Joe Rattz: "Re: IIS 6.0 Not Caching Images"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
