While Salesforce may be one of the largest and longest operating SaaS applications, it has not grown its geographical footprint as fast as Microsoft, Google, or other cloud service providers. Salesforce has only built out 9 regional data centers (10 if you include a San Jose PoP that as far as I can tell doesn’t house any production instances). And its internet peering? Salesforce at the moment is only listed on 5 exchanges with a total of 70Gbps of capacity. This doesn’t count any ISP transit that Salesforce may buy from ISPs at its data centers which could be worth anther 30-50Gbps. In comparison, Microsoft has placed its Office365 stack in over 25 data centers and peers on approx. 100 internet exchanges, each with 10-100Gbps of bandwidth.
In addition to Salesforce’s unenormous footprint, by design, each of its customer organization’s data and force.com applications are not distributed. They exist on what Salesforce calls pods in only one of Salesforce’s data centers in Ashburn, Chicago, Dallas, Phoenix, London, Frankfurt, Paris, Tokyo, Kobe.
Salesforce Pod: n. – a full stack of equipment located in one of Salesforce’s data centers needed to operate the Salesforce stack (Database servers, Application Servers, Routers, Firewalls, Etc.) running multiple customer instances in a multi-tenant fashion.
That means that no matter where your users are, every time they load a page, download a file, or run a VisualForce report, they are making TCP calls to a data center that could be across the country or on another continent. Unfortunately, TCP does not like long distances or congestion, both inherent in internet routing. To fix this, you need to optimize connectivity to the Salesforce data centers where you pod is hosted.
Want to know where you pod is hosted? Check out the map below.
Take Action: How to Improve Salesforce.com Performance
When your users complain Salesforce is slow while their Office365 continues to rock, here a a few ways that you might be able to help optimize your connectivity to your pod for better performance
- Ask Your ISP to Fix Your Route Path – If your ISP is one of the few that peers directly with Salesforce like Level3, Comcast, NTT, Verizon, or Integra Telecom, your ISP should work with you to optimize BGP in order to provide lower latency or higher reliability routing. Just ask.
- Add a WAN Accelerator – Due to the long pathways to get to Salesforce, users often run into long latency and unreliable connections to their Salesforce pod. TCP, the common protocol for fetching Salesforce data, breaks down over long distances and congestion. WAN accelerators like those from Riverbed and SilverPeak can optimize TCP by deduplicating, compressing, and optimizing TCP flows so that more data can be transferred to the user’s browser in a shorter amount of time.
- Move your Internet Gateway Closer to your Salesforce Pod – Identify which Salesforce Pod you are on by checking out the header when you log in. If you are in North America, you should this will be NA2-NA63 (ex. na8.salesforce.com) Once you’ve identified where your Salesforce pod is using the provided map, you can bring your network closer to it by buying internet from an ISP in a market or better yet, the data center, or internet exchange where Salesforce connects to the internet. Organizations that peer on the internet exchange with Salesforce are in essence one network hop away from Salesforce and their Pod. This strategy will minimize the congestion effects of the internet minimizing latency and maximizing TCP throughput. Salesforce will even allow you to connect directly to them privately, but only in Ashburn, VA and San Jose, CA. However, if you’re pod isn’t located in one of these markets, this may actually worsen performance due to inefficient routing.
