For some reason a new web application on my development VM always returns a 503 Service Unavailable when you go to it.
It turns out that this is due to the app pool supporting 32 bit applications! Change the setting in IIS (App Pool > Advanced Settings > Enable 32 Bit applications should be false)
Really, this is just a link to the MSDN article “How to Optimize a SharePoint 2007 Web Content Management Site for Performance“. Nice easy title.
It does mention a particular irritation of mine – that many (most?) systems don’t use any kind of compression on static content. I remember seeing Apache admins complaining about people not using compression, oh, 10 years ago. In SharePoint, this is such a waste! JavaScript and CSS files are lovely and compressible – and core.js is big. So is Core.css. Doesn’t seem much reason not to enable it!
To do so, open IIS Manager, and right click on the ‘Web Sites’ folder. Select the service tab, and check the check box. Don’t go for dynamic compression; this would be a bad idea.
You’ll also want to check/edit the file types compressed. See Using HTTP Compression for details, and you’ll probably need to add the .JS and .CSS extensions.
I must sit down and give this a proper test some time. Certainly I don’t see the same sizes in the article, but then I’m looking at the file sizes on disc; in 12 Hive, and in the temporary compression cache (typically %WinDir%/IIS Temprorary Compressed Files). My numbers show Core.js to be 575Kb uncompressed, 91Kb after compression. Nice!
I had a call from a colleague today. He’d created a SharePoint site collection inside an existing and working web-app, using the standard ‘sites’ managed path (e.g. http://server/sites/newSiteCollection). It seemed to have created it okay, but if he went to it he got a HTTP 404 – yup, “Page not found”.
This seemed a bit weird, so I went to see what he’d done wrong. I looked in Central admin – it showed his site collection as existing, but going to it, I got a 404 too. So I created my own – and after it was create, if I went to it, it 404’d too.
(The examples below use the managed path ‘demos’ – I took the screenshot when I was reproducing the problem, having apparently fixed it for the ‘sites’ managed path already. Trust me, this happens just the same if the items involved are using the text ‘sites’).
If you look at the screenshot you’ll see that I’m trying to go to the site collection ‘vaa’ inside the ‘demos’ managed path.
Well, at this point I tried using some other managed paths to create a site collection, and they worked fine – no 404s when you try going to them just after creation. I began to wonder if it was something about this path, so I opened IIS Manager to see if anything was going on.
Inside my virtual directory for my web app, I found a ‘sites’ folder (or ‘demos’ in this screenshot):
That was a bit strange – normally I wouldn’t expect to see ‘sites’ folder. It seemed empty, so I deleted it, and then I could access my new site collection without getting a 404. I then created a folder to interfer with one of my working managed paths (I created a folder called ‘demos’), and suddenly I started getting 404 errors if I tried going to it.
I don’t know why there was a ‘sites’ folder in that virtual directory, but it was definitely causing problems. I guess I won’t be using a managed path of ‘bin’ or ‘aspnet_client’ then 🙂
Andy Burns' Blog 