MOSS Has Got Game - Glu Mobile’s Website (www.glu.com) - How We Did It - Part 3 of 3
Welcome to the third and final entry in Allin Consulting’s guest blog series on how we built the Glu Mobile web site. Check out Part 1 and Part 2 if you have not already read them. In this post, we will focus on the software architecture and techniques that we used to increase site performance. Our hardware architecture follows the best practices in sizing a farm of 3 web front-ends, 1 application server, and a 2-node SQL Server cluster, so we will not go into hardware architecture in this post. Beyond having a solid hardware architecture, we recognized that meeting the requirements of our project would mean optimizing performance through a lightweight custom framework in order ensure a positive user experience, especially with the requirements of rich graphics, media, and content targeting that a gaming site would demand.
To begin, let’s break down the three main processing components that impact performance for public facing sites built on MOSS, which are in common to all web sites:
The first is the MOSS server with all of its attendant features and collaboration extensions, the second is the Internet itself, and the third is the client web browser. We will break down the techniques we implemented to address performance issues for each component.
MOSS Server Application
The first performance issue was around the amount of rich data and data relationships required for the Glu site. A key requirement was to target games and content to users based upon their profile preferences of country, language, mobile carrier and mobile handset. There are approximately 300,000 combinations of Country/Carrier/Handset/Game in the database. Minimizing database reads was critical with all of these potential combinations. To solve this, we created an “application” object that is placed in the IIS application collection and serves to cache this information. The graphic below illustrates all of the major components of framework of our solution.
Glu Application Object
The Glu Application Object sits at the center of the architecture and contains the cache of all MOSS data (Games, Genres, Ringtones, Countries, Carriers, Handsets, etc.) displayed in the site along with all of the linking relationships between this data. When the application is first started, the cache data is loaded and made available to all users. The cache can also be refreshed via our Glu Content Manager as needed when new games and content are published. (The Glu Content Manager is a set of web part pages with views into SharePoint lists.) By creating this cache, the server is simply working with pre-sorted and pre-linked data. This frees up the server from “busy” repetitive processing and makes all of the critical data available in memory for fast access.
On top of the Application Object, we layered our custom server controls and web parts which we discussed in Part 2. This reads and renders the content, content references, and relationships from the custom cache. Our Application Object combined with the SharePoint caching features and SQL Server caching capabilities results in very favorable response times from the server infrastructure. Though it depends on your Internet connection, over DSL and better, we see the site's pages fully rendered within 2-4 seconds fairly consistently. The biggest latency is from the media trailers (the animated trailers you see embedded in the cell phone graphic) and the Java game emulators, which are served from different media servers separate from the SharePoint farm.
Get the Space Out – Reducing Page Size Over the Internet Pipe
To reduce the size of each rendered HTML page for transmission and also reduce the amount of white space processing by the web browser, we created a custom white space filter. Do a View | Source from your browser on any page on the site and you will see the results as shown in the graphic below.
While this may appear like extra server processing without a great page size reduction, we in fact found an average size savings of 5K per page. Also the rendering time in the client browser was reduced by a noticeable amount of time – 1 to 3 seconds. So with a little extra processing on the server, we reduced the overall impact on the Internet traversal as well as the rendering time in the client browser.
JavaScript Weight Reduction – The Client Browser
So much of page weight in SharePoint is JavaScript related. For end users on most public facing sites one does not need all of collaboration and publishing functionality of SharePoint. In our continued efforts to reduce page weight and streamline the code that the browser must process, we created a JavaScript server class that dynamically creates the appropriate script based on user type and browser. If a user is not authorized to do content publishing, we do not serve up any of the SharePoint required JavaScript for those publishing actions. For browser compatibility, we dynamically generate the appropriate JavaScript server-side instead of streaming down a set of conditions to test for different browsers. The following output shows the different script rendered for Netscape and IE:
Also, to reduce the number of page requests, we utilize JavaScript where feasible to cycle through elements of games as well as screenshots and wallpapers. When you go to a game page, the game overview, features, screenshots, try it and get it functionality are all implemented with JavaScript to avoid a round-trip to the server.
We tried a number of ways to maximize the user experience for loading all of the Flash-based trailers. The only Flash content on the site are these trailers. We settled on post-loading the trailers and game emulators by 2 seconds because this allowed the page to render before streaming starts. The trailers and emulators are served up from a separate media farm, which avoided any impact to the SharePoint farm.
Summary
Performance optimization is critical to achieving a positive user experience for any public facing web sites. For our implementation of Glu Mobile, the key elements were storing data and accessing it as much as possible from RAM and then intelligently serving up only the required minimum page load over the wire to the client browser. If you just deploy out of the box, you may be introducing unneeded features and page weight to users that don't use the rich collaboration features of MOSS. Target these functions to your internal users, and slim down the page weight to your public users by using some of the concepts and techniques we've described here. Also, expect that you will be continually fine tuning your implementation to deliver the best end user experience. The white space filtering mechanism came out of some of those fine tuning sessions where we were just trying to shave as much weight off the pages as possible.
Our thanks to the SharePoint team for the opportunity via this 3-part blog series to provide a little insight into how we built the Glu Mobile site. We encourage you to check out the site, register, and try a game on one of the emulators. Though the pricing is not on the site as the selling experience is integrated through SMS and is added to your wireless bill (another cool little feature we integrated), the games themselves are only about US$6-9 apiece. You can hone your gaming skills with a little Project Gotham Racing on your mobile phone. :-) If you have any questions, please leave a comment here or e-mail us at glu-team@allincal.com.
The Glu.com Team at Allin Consulting
- Shawn L. Parker - Solutions Architect
- Robert Sweeney - Sr. Consultant
- Eric Hansen - Project Manager
- Stefan Nilsson – Practice Manager
- Karl Kuhnhausen – Practice Director
