Bandwidth Required for Users

Salesforce.com is designed to use as little bandwidth as possible so that the site performs adequately over both high speed, dial-up, and over the air Internet connections.

• While average page size is on the order of 90KB, salesforce.com uses compression as defined in the HTTP 1.1 standard to compress the HTML content before it is transmitted as data across the Internet to a user's computer. The compression often reduces the amount of transmitted data to as little as 10KB per page viewed due to the lack of image content. The site was designed with minimum bandwidth requirements in mind, hence are extensive use of color coding instead of images. Our average user also is known to view roughly 120 pages from our site per day.

• Our application is stateless, therefore, there are no communication requirements in the background once the page loads like traditional client server applications e.g. Outlook. Therefore once the page loads there are no additional bandwidth requirements till a user queries or writes information to salesforce.com.

• In practice we have found the bandwidth requirements for other commonly used programs place a much higher demand on Internet bandwidth. We have found through working with our customers that email (business & personal), email attachments, News, streaming video, stock update, place a much greater strain on the available bandwidth. We recommend the customer measure all activities to make sure they are evaluating a holistic demand on their network services. For example, is the Account Executive sending a 7MB marketing brochure or PowerPoint presentation to a customer.

• The application of the formula "Peak bandwidth/number of users = average bandwidth per user" does not accurately portray the average bandwidth usage by the average user at salesforce.com. Salesforce.com handles considerably more transactions per second in aggregate from all our customers than any one individual customer would see from their end (since not all users would be actively loading pages simultaneously).

In short, it is difficult to specify customer bandwidth because of the nature of the Internet and individual corporate usage. Network latency, peering issues, bandwidth at upstream providers, users using their Internet connections for other use besides salesforce.com, etc. all affect the perceived performance of the connection and the amount of bandwidth required to keep performance adequate.

However we have had some success in understanding customer's requirements by considering the number of users, the think time between transactions and the average response time.

Bandwidth = P * U / ( T + R)

P = Average page size in Kilobits as opposed to kilobytes - This conversion is necessary as bandwidth is measured in bits and not bytes (8 bites to a byte). The average salesforce.com page size when compressed is typically in the range 10 Kilobytes - 20 Kilobytes or 80 kilobits - 160 kilobits. The midpoint is 120 Kilobits.
U = Number of logged on users, assume a concurrent logged in rate of 50 - 75% of user community.
T = User think time between transactions in seconds, typically figures here range from 10 seconds - 40 seconds in call center/service environments to 120 seconds - 300 seconds in sales environments
R = Average response time in seconds, use an average of 1 - 2 seconds per page refresh

For example:
Salesforce.com deployment of 80 users with 75% of the users concurrently logged in with a think time between transactions of 2 minutes:
Avg Bandwidth = 120 * 60 / ( 120 + 2 ) = 59 Kbits/sec

In a sales environment an active user would typically conduct around 15 - 20 transactions per hour.

HTTP 1.0 versus HTTP 1.1
Typical web pages (a HyperText Markup Language (HTML) document), contain many embedded objects - today twenty or more embedded objects are quite common. The large number of embedded objects represents a change from the environment in which the Web transfer protocol, the Hypertext Transfer Protocol (HTTP) was originally designed.

As a result, HTTP/1.0 handles multiple requests from the same server inefficiently, creating a separate TCP connection for each object. Each of these is an independent object and retrieved (or validated for change) separately. The common behavior for a web client, therefore, is to fetch the base HTML document, and then immediately fetch the embedded objects, which are typically located on the same server.
The recently released HTTP/1.1 standard was designed to address this problem by encouraging multiple transfers of objects over one connection.

HTTP/1.0 opens and closes a new TCP connection for each operation. Since most Web objects are small, this practice means a high fraction of packets are simply TCP control packets used to open and close a connection. Furthermore, when a TCP connection is first opened, TCP employs an algorithm known as slow start. Slow start uses the first several data packets to probe the network to determine the optimal transmission rate. Again, because Web objects are small, most objects are transferred before their TCP connection completes the slow start algorithm. In other words, most HTTP/1.0 operations use TCP at its least efficient. The results have been major problems due to resulting congestion and unnecessary overhead.

HTTP/1.1 leaves the TCP connection open between consecutive operations. This technique is called "persistent connections," which both avoids the costs of multiple opens and closes and reduces the impact of slow start. Persistent connections are more efficient than the current HTTP 1.0 practice of running multiple short TCP connections in parallel. NOTE: These persistent connections are only open for the duration of the page load � they do not remain open in the background.

HTTP/1.1 also enables transport compression of data types so those clients can retrieve HTML (or other) uncompressed documents using data compression; HTTP/1.0 does not have sufficient facilities for transport compression.

The following study showed that aggressive use of additional compression could save almost 40% of the bytes sent via HTTP:

Jeffrey C. Mogul, Fred Douglis, Anja Feldmann, and Balachander Krishnamurthy.
Potential benefits of delta encoding and data compression for HTTP.
In Proc. SIGCOMM '97 Conference, pages 181-194, Cannes, France, September 1997. ACM SIGCOMM.

Therefore we recommend at all times our customers use browsers that adhere to the HTTP 1.1 standard as it creates a number of efficiencies while using our service.

Relevant Solutions:
Use HTTP 1.1 through proxy connections:
https://na1.salesforce.com/501300000000grZ