The final push begins tomorrow
July 9th, 2008 | Published in Google Orkut
The big day is almost here! Tomorrow marks the beginning of the final stage of the application roll-out to orkut users, giving you several hours to get your apps in tip-top shape in order to handle the expected traffic increase ahead.
If you haven't already, it is absolutely imperative that you read the Latency Tips for orkut. It presents a number of techniques and best practices that you can take advantage of, even within the next few hours, to get your application up to speed.
Among the techniques listed is the use of Preload elements in your app spec. Preload elements allow for makeRequest responses to be preloaded while the gadget is rendering. If you use a lot of static makeRequest calls in your application (e.g. retrieving a user's high score or a list of gifts that have been sent from your app), taking advantage of pre-loading can make a big difference in the response time of your application. More information on pre-loading is available here.
One other technique that you may find useful is automatic URL rewriting. During preprocessing, orkut can automatically replace the URLs for static content (e.g. JavaScript files, style sheets, images, etc.) with proxied URLs, significantly reducing both the load on your servers and the loading time for your users. While rewriting is automatically enabled in the sandbox, you will have to opt-in in www.orkut.com. Instructions on how to do this are provided here. Make sure to thoroughly test your application if you opt in to rewriting, although you shouldn't run into any problems if you specify absolute URLs to your resources.
As a final note, please make sure that caching is enabled for your application's resources, particularly images and other large files that your app loads frequently. Due to a caching bug that affected many apps last week, you may have opted out of caching completely. This bug was patched last week, and orkut's caching infrastructure now honors both the Cache-Control and Expires headers returned by your application's host with a minimum refresh rate of five minutes. Please make the necessary changes to your server configuration to set your cache to expire at most once per hour (the default duration if no cache control headers are set). Not only will this take some strain off of your own servers, but your users' experience will improve greatly as a result.
We'll be monitoring the performance of your applications. If we see your servers buckle under the increased traffic, we will suspend your application by removing it from the directory and user profiles until your host can be updated to accommodate the traffic. We really don't want to do this, so use the next several hours to read the tips and get your apps ready.