performance
Recently, I was troubleshooting performance issues on a few different websites, and was stymied by the fact that YSlow repeatedly reported an F for "Compress components with gzip," even though online sites like GIDNetwork's Gzip test were reporting successful Gzipping of text components on the site.
Yslow results - not very happy.
After scratching my head for a while, I finally figured out the problem, hinted at by a comment on a question on Stack Overflow. Our work's proxy server was blocking the 'Accept-Encoding' http header that is sent along with every file request; this prevented a gzipped transfer of any file, thus Yslow gave an F.
I set up a secure tunnel (using SSH) from my computer to the web server directly, and then reloaded the page in FireFox, and re-ran YSlow:
Much happier now. I've contacted our IT department to see if it's possible to allow the proxy server to pass through the Accept-Encoding headers, but for now, I'll know to watch out for false positives on the YSlow test, and check from multiple locations.
I posted a story over on Open Source Catholic today concerning page caching and its importance for saving a server under a heavy load (read: the slashdot effect). You can save a lot of resources on your server by not only using built-in page caching on your favorite CMS, but also exploring further options (for Drupal, there's Boost (read our case study on Boost); for WordPress, there's WP Super Cache). From OSC:
A couple months ago, the Archdiocese of Saint Louis announced that a new Archbishop had been chosen (then-Archbishop-elect Robert J. Carlson). For the announcement, the Archdiocese streamed the press conference online, then posted pictures on the St. Louis Review website of the day's events (updated every hour or two).
During this period of time, the Archdiocesan website had over 2,000 visitors per hour, and almost all the visitors were hitting the home page. The website (run on Joomla 1.0.x) didn't have many caching mechanisms in place, and for almost a complete hour, the website was returning server errors as the processor was pegged at 100% utilization. Something had to be done!