Comments on Chris O'Brien: Optimization, BLOB caching and HTTP 304s

Chris, thanks for this write up. It's very hel...

2011-02-23T10:42:58.101Z

Chris, thanks for this write up. It's very helpful and informative.

@Maxime, Aha - very interesting to hear that'...

2009-06-14T10:18:56.387+01:00

@Maxime,

Aha - very interesting to hear that's a confirmed bug, particularly from an MS person!

Many thanks for the info.

Chris.

P.S. Agree that if designers need access to the files, an alternative library which Fiddler shows does BLOB cache properly might be more appropriate than filesystem.

Thanks Chris for the info, good post. It's a ...

2009-06-12T23:28:00.428+01:00

Thanks Chris for the info, good post.

It's a known bug that isn't fix nor planned until SharePoint 2010. I'd suggest using a different library to store your custom CSS/JS/XSL.

The problem with file system folders will be to synchronize them across multiple servers, especially if you allow designers to touch your styles.

Maxime

Thanks for your reference to my post on Blob cachi...

2009-05-28T15:28:13.606+01:00

Thanks for your reference to my post on Blob caching and 304's Chris! - Mike

Doing something with a HTTP module or similar - ye...

2009-05-22T18:12:25.460+01:00

Doing something with a HTTP module or similar - yep, that's a good thought.

Although I guess one could probably argue it would be simpler/more efficient to just store the files somewhere else. Still, good to have the workaround if for some reason the files have to be stored in the Style Library e.g. for an existing site.

Thanks,

Chris.

I see this behaviour also in multiple browsers (ev...

2009-05-22T16:48:05.665+01:00

I see this behaviour also in multiple browsers (even IE8). It is strange that authenticated users do get a max-age according to the max-age in the blobcache and anonymous users get a max-age of 0. The internet is full of anonymous users...
And the performance bottleneck is as Chris says the round trip.
Perhaps a custom http adapter that adds/changes the max-age header can also be a solution if there is no reverse proxy involved?

@Tyler, @michhes, Unless I'm missing something, I...

2009-05-21T12:51:09.080+01:00

@Tyler, @michhes,

Unless I'm missing something, I see the same behaviour in both browsers. If I check the request for a certain Style Library file in both IE/Fiddler and FF/Tamper, I see the same If-Modified-Since and If-None-Match data. So that's one thing, but in any case - isn't the issue that the request/subsequent 304 is happening in the first place for anonymous users? Regardless of the lower level headers, surely the thing I care about is that the round-trip is occurring and is therefore slowing down page loads - the browser wouldn't make this request if the file was initially served correctly.

It sounds to me like solutions like michhes's reverse proxy approach are the only way to combat this currently - I'm curious if this was implemented here because the servers are in Western Australia but site users might be in other continents, so this is exactly the kind of optimization required?

Thanks for the comments..

Chris.

We work around this on www.westernaustralia.com an...

2009-05-20T11:24:26.948+01:00

We work around this on www.westernaustralia.com and other sites by doing some cache header rewriting on our reverse proxy using FilterProxy. The reverse proxy sits between the WFEs and the internet and handles all content being shunted down the line. As all of our sites are served through the proxy this also makes life easier as we don't have to configure caching at the IIS site level.

I've also noticed differences between IE and FF (FF always seems to issue the conditional get but maybe that's just due to browser settings).

Does this behave consistently across browsers? Fo...

2009-05-20T07:31:11.271+01:00

Does this behave consistently across browsers?

For FireFox, when some asset gets pulled from the Style Library yes it's true that it gets a Cache-Control of private,max-age=0...but there's also an ETag and a Last-Modified header that get sent in the original response.

Other browsers will pick these up and the next time they send a request they'll send If-Modified-Since and If-None-Match headers (in addition to Cache-Control).

When SharePoint gets these it will hand out the appropriate response code 304 (Not Modified).

Could it be that this "bug" is in IE 6/7 and is fixed in future MS browsers?

Put fiddler away for a sec and have another look with FireFox and Tamper data. The fresh set of eyes may change your mind.

My Best,
Tyler

Personally I think this is a huge bug. Someone has...

2009-05-19T14:48:00.000+01:00

Personally I think this is a huge bug. Someone has noticed it back in 2007 in a comment on this post:
http://blogs.msdn.com/ecm/archive/2006/11/08/how-to-make-your-moss-2007-web-site-faster-with-caching.aspx

I don't understand that MS doesn't fix this. Even SP2 doesn't.