Problem:
========================================
SharePoint site takes 25-40 seconds to load initial web page when accessed from overseas sites.
SPS Web server in Toronto is accessed quickly when the client is local, but takes a long time when accessed from Australia, for instance.
Solution:========================================
Traces have been taken from client and server, and we intermittently see a substantial delay between client sending an HTTP GET and server responding, as well as a delay in establishing the initial session. However, there is no way to determine where exactly in the path between the machines the delays are introduced.
The traffic flow is as follows:
Client----->Internal Switches-----> Certeon Application Accelerator-----> Router-----> MPLS Cloud-----> Router-----> Certeon Application Accelerator-----> Internal Switches-----> Web Server
Also of note is that after the initial delay in loading the website, further navigation of the site is done with acceptable performance.
Local Toronto clients do not access the site through the Certeon, but go direct via LAN, and see no delays. So this should eliminate the server config as an issue.
All remote clients experience the delays, some greater than others, generally corresponding to how far away the client is. For instance, clients in Perth see about a 28 second delay in loading the site, while clients in Salt Lake City see a delay of about 15 seconds. This leads us to suspect that the MPLS cloud routing and infrastructure is introducing the delay, but we need to trace on both sides of the
Certeon to eliminate it as the cause.
The Certeon translates the IP address of the client, and also alters the port on which the connection is made to the server, and so it is not possible to correlate packet for packet the communication between client and server captured in the traces.
In order to remove the Certeon devices from the environment, we disabled its functionality on both sides of the connection, effectively allowing all traffic to pass through the devices unaltered. This now allows us to see the full communication between client and server with correct port assignments and IP addresses, and we see that there are actually no intermittent long delays recorded
at all, and the full download of the site legitimately takes a full 28 seconds based on the amount of data over the latency of the connection.
========================================
SharePoint site takes 25-40 seconds to load initial web page when accessed from overseas sites.
SPS Web server in Toronto is accessed quickly when the client is local, but takes a long time when accessed from Australia, for instance.
Solution:========================================
Traces have been taken from client and server, and we intermittently see a substantial delay between client sending an HTTP GET and server responding, as well as a delay in establishing the initial session. However, there is no way to determine where exactly in the path between the machines the delays are introduced.
The traffic flow is as follows:
Client----->Internal Switches-----> Certeon Application Accelerator-----> Router-----> MPLS Cloud-----> Router-----> Certeon Application Accelerator-----> Internal Switches-----> Web Server
Also of note is that after the initial delay in loading the website, further navigation of the site is done with acceptable performance.
Local Toronto clients do not access the site through the Certeon, but go direct via LAN, and see no delays. So this should eliminate the server config as an issue.
All remote clients experience the delays, some greater than others, generally corresponding to how far away the client is. For instance, clients in Perth see about a 28 second delay in loading the site, while clients in Salt Lake City see a delay of about 15 seconds. This leads us to suspect that the MPLS cloud routing and infrastructure is introducing the delay, but we need to trace on both sides of the
Certeon to eliminate it as the cause.
The Certeon translates the IP address of the client, and also alters the port on which the connection is made to the server, and so it is not possible to correlate packet for packet the communication between client and server captured in the traces.
In order to remove the Certeon devices from the environment, we disabled its functionality on both sides of the connection, effectively allowing all traffic to pass through the devices unaltered. This now allows us to see the full communication between client and server with correct port assignments and IP addresses, and we see that there are actually no intermittent long delays recorded
at all, and the full download of the site legitimately takes a full 28 seconds based on the amount of data over the latency of the connection.
No comments:
Post a Comment