interfacing SharePoint with Akamai

jimmiet — Sun, 14 Jun 2009 17:53:00 GMT

What is Akamai?

Think of Akamai as a very intelligent, caching, reverse proxy server, which sits in front of your SharePoint farm. External user requests go to Akamai servers first. If Akamai has the content cached, it serves the content directly back to the client; otherwise Akamai requests the content from your SharePoint farm and then sends it to the client. Akamai does intelligent caching; that is, it can cache static portions of a page like images and stylesheets, while still getting the dynamic parts of the page from your SharePoint server. In any case, the client never directly hits your SharePoint farm.

Akamai is much more than just a reverse proxy server. Akamai has many farms of servers (at last report, more than 20,000 servers) distributed in 70 countries. Akamai has a dynamic mapping system, which uses heuristics and network performance historical data, to route the client request to the optimal Akamai farm.

Your SharePoint farm is referred to as the “origin farm” in Akamai literature. The basic content flow is illustrated in this table.

User browser makes request.

Request routed to optimal Akamai farm

Akamai (Edge Server) checks cache, requests non-cached content.

Request non-cached content

Origin (SharePoint Farm) generates non-cached or dynamic content

Client browser renders Akamai’s response

Akamai combines origin’s response with locally cached content

Origin responds with content

Akamai is the only external user your origin farm will see. Due to this, blob and output caching is usually of limited benefit when using Akamai.

Working with Akamai

You contract with Akamai for its services. Akamai will assign a representative who will assist you in setting up origin farm to communicate with Akamai’s edge servers, and in configuring the Akamai edge server to meet your application’s needs. Akamai provides training and support as needed.

You should plan on several weeks to get everything working.

The high level steps are:

If using SSL, install an SSL certificate on your origin farm, and provide Akamai the certificate information so Akamai can request and install SSL certificates on the Akamai edge servers.

Create a DNS record for your origin farm. The naming convention is your origin URL prefixed with “origin-“; for example, “origin-www.litwareinc.com”. Akamai will take over your URL; that is, www.litwareinc.com. Akamai refers to your URL as a digital property. Your contract with Akamai can include multiple digital properties; for example, if you are exposing multiple SharePoint web applications through Akamai.

Configure the Akamai edge server behavior. The Akamai representative will provide you credentials to access the configuration console. Some of the more important configuration parameters are:

a. Whether to use SSL.

b. The origin farm URL and port number if non-standard.

c. Cache key format, and whether to ignore case when comparing cache keys.

d. Compression to use when communicating with the origin farm.

e. Time to Live (TTL) rules, which determine what types of content Akamai should cache, and for how long.

f. Prefetch rules.

4. Testing the Akamai configuration. Akamai has extensive reports to help you identify and tune page performance by adjusting the caching rules and other edge server settings.

5. Go Live. You can access the Akamai portal to periodically review performance reports, so you can adjust edge server configuration as needed.

SharePoint Publishing – Cache Invalidation

Akamai is most beneficial in content publishing scenarios; that is, where most users are anonymous and the content is mostly static. This scenario makes the caching provided by Akamai most effective. This translates to a SharePoint publishing portal. Since edge server cache TTL should be as long as possible, there needs to be a way to notify the edge server when a new page version has been published; thereby forcing the Akamai cached version of the page to be refreshed. Akamai provides the Content Control Utility (CCU) web service for this purpose.

The CCU is a SOAP web service that allows you to specify the refreshing of specific cached objects, or to remove specific objects. The CCU provides the option of using invalidation-based or removal-base refreshing. Requests are propagated through the Akamai network, and most removals are completed within 10 minutes of the request. One limit is that files submitted for CCU requests should contain no more than about 100 URLs per SOAP request. Your Akamai representative will give you the end-point URL for this web service, and a user name and password required for authentication to the web service.

A typical SharePoint configuration is to have an Authoring farm when content pages are created and edited. Content deployment jobs periodically push new page versions to the Public farm, which is the origin farm. To automate the CCU web service calls, you can install event handles in the Public farm. The event handlers call the CCU web service for new, changed, and deleted pages. The architecture might look like the following diagram.

Event receivers are installed on all libraries and lists which contain content that can be changed by authors. This includes modifications by Content Deployment jobs, or manual copying/deleting of assets in the Public farm. The asynchronous (after) events are used to minimize performance impacts. The event handler is installed the Global Assembly Cache (GAC). This allows it to be called from any site in the Public farm. The event handler packages the URLs and then sends them to Akamai’s CCU web service.

These events are captured by the event handlers:

¾ ItemDeleted

¾ ItemUpdated

By default these libraries and lists in the public portal root site collection, and every subsite, should have event receivers installed. Additional lists and libraries may be added as needed.

¾ Pages Library

¾ Site Collection Image Library

¾ Site Collection Documents Library

¾ Style Library

¾ Images Library

¾ Reusable Content List

A SOAP request is formatted according the Akamai’s Content_Control_Interfaces.pdf document. The Akamai user name and password are stored in SharePoint’s single sign-on repository for protection. SharePoint object model calls are used to retrieve the user name and password to make the web service call. The invalidate action is specified to minimize impact if the cache does not truly need to be updated. The response code is checked to determine if a retry is necessary.

It is most effective to use asynchronous methods to call the CCU method, to prevent excessive blocking if the CCU web service is slow in responding. The async call might look like this picture.

The async response handler would look like this picture:

Conclusion

Akamai can provide a huge performance boost for public portals serving global audiences. Most of the effort to set up Akamai is transparent to SharePoint. The exception is the need to forcefully update the Akamai cache when new content is published. Cache refreshing can be forced by calling the CCU web service provided by Akamai.

Jimmie's Sharings : SharePoint Akamai

interfacing SharePoint with Akamai

What is Akamai?

Working with Akamai

SharePoint Publishing – Cache Invalidation

Conclusion