Use the power of the Internet to scale your portal

By: J Schwan

Did you know that regardless of your infrastructure, you have the largest, most powerful performance enhancing platform in the world at your disposal? This platform is vast, infinitely scalable and most of all, it's free. What is it and how do I sign up? It's the Internet itself! Let me give you an example of how to take advantage of this.

My company does a lot of portal implementations and customization. Portals are great for users because they consolidate content and services from across an enterprise and present the information in a unified, consistent user interface. iGoogle is a great example. Portals are also a pain in the butt for developers, mainly because of the dozens of integration points that often make up a personalized portal page. The top right corner may be pulling weather information, underneath it a customized stock portfolio, under that company announcements, info from your HR profile, personalized lists of your client accounts, etc. Each of these blocks of information (or portlets) makes and individual call to retrieve its specific information. So one call to your portal page often turns into dozens of portlet requests to your data center. That load adds up quickly and makes performance and scaling a challenge.

Regardless of whether you're running a portal or not, the key to good performance (and ultimately scaling) for any web site is caching. A great rule of thumb is, the closer the content is cached to the end user, the faster it's delivered. If the content is cached in their browser (e.g., an image) bingo, it's there. If you have to go back to the web server to retrieve a pre-generated HTML page, it's a bit slower. Have to go back to the app server (behind the web server) to run some logic to create the HTML page, slower. Have to go back to the database to pull some data the app server needs, slower still. Have to go to some external ERP or a content provider, slower, slower, slower.

There are several persistent and in-memory caching options out there that you can use to avoid multiple trips to external systems. But what about avoiding trips to your data center all together? This is where the Internet comes in.

Every request (from a user) and response (from a server) sent through the Internet hops across several intermediary servers between your data center and the user's web browser. At each of these hops, the intermediaries check what are called "response headers" to see how long they can cache the data that has been made from previous requests. That means when person "A" requests weather for Chicago, if your system is designed correctly, the next person will get the same information without having to go to your data center to get it.

The key to enabling this caching is twofold. First, customize the URL to be specific to how you want data to be cached. Second, use the response headers' cache-control directive to determine how long that URL's data should be cached (i.e. one hour, one day, one week, etc.).

For example, if your page's or portlet's URL is "http://www.mycompany.com/weather" and the responsibility is on your web server to figure out where that user is from and serve up weather appropriately, caching on intermediary servers is not going to do anything but cause problems. But if your URL is "http://www.mycompany.com/weather/Chicago," now you have a specific request that can be cached for up to 12 hours. Any subsequent requests by Chicago-based users aren't going to hit your data center and will be served up by intermediary servers. This decreases load on your servers, increases performance and quickly adds up to huge hardware savings.

The same trick can be applied to any relatively static information. Use response headers to cache information that isn't going to change that often. And if the information is personalized, figure out how to bake that personalization/segmentation into your URL so the context-specific data can still be cached by intermediaries. This may not apply to exclusive information (i.e. account balances) but if you utilize AJAX and REST in your page creation, that can be a small hit to your data center, while the rest of the page is rendered from cached information on intermediary servers.

So use the power of the Internet to your advantage to scale effortlessly. If you think about most page's makeup there is a very small part that is truly user-specific. The rest of it can be served up by the Internet at large, and that's a great way to scale without spending a dime!

J Schwan is the CEO and Founding Partner of Solstice Consulting, a full-service, IT consulting firm headquartered in Chicago.