New job, new problem. We’ve a SharePoint 2010 Publishing site using content deployment to push content from an authoring site collection to a live one – and the live site collection started to return an HTTP 401 – Unauthorized to any request for a page.
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.
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!
A short, useful article about setting a machine up as a mail server – this proved useful when I was setting up a machine for a demo recently. I must confess, I’ve never set up a mail server before, but it was quite simple, apart from the problems I had with finding the right Windows Server installation disc.
Note to self: I keep needing/using this tool to avoid IISRESETs during SharePoint development. Much faster…
I was having a bugger of a time setting up an SSL connection using a test certificate until I found this article by John Howard. One thing I would say – when using MMC to look for newly created certificates, remember to ‘refresh’ the view. Otherwise this works – shame I don’t entirely understand how… … still, at least my error “The server mode ssl must use a certificate with the associated private key” is now gone…
I just got Rails working on Apache, which is pretty cool, and fairly straight forward really. My big complaint about the whole process is, though, that the tip below was necessary to make apache stop just returning errors…
Note from porter.ea:
One additional edit that I found necessary was to add “#!c:/pathto/rubybin/rubyw” (note the “w”) at the top of the “C:appnamepublicdispatch.fcgi” file.
It’s worth noting the bit about (for performance):
FastCgiConfig -maxClassProcesses 1 -maxProcesses 1 -minProcesses 1 -processSlack 1