Frame Relay -HQ-remote offices slow connection

Jun 25, 2007 5 Replies

This link for troubleshooting would not help me

formatting link

Frame Relay -HQ-remote offices slow connection open original image

I have been given this scenario :



remote offices are connected to head quarter through WAN Frame Relay Connection, speeds of these frame connection are either 64 kbps or 128 kbps.



users in remote site experience slow connection to their head quarter. Applications are used as oracle database


What steps of troubleshooting should I follow to find out the source of the problem ? is the bandwidth 64 or 128 are enough of 20 users or more at each site ?



I do not have router's configuration to look at it



This link for troubleshooting would not help me

formatting link


me

formatting link
It completely depends on how the application works. If its high bandwidth and you are doing good-sized queries with decent return volume, then yes 64 vs 128 k is very very small and will probably be your issue. Get a snmp bandwidth monitor to watch the serial interfaces, or issue a show interface when the issue is occurring and check your transmit vs. receive. If you are seeing 200+/255, then yes your pipe is getting hammered and there is nothing you can do but either upgrade your WAN or try to work with the application teams to write better queries or figure out some kind of night time replication. At the core of this issue, 128 is only 16 kilobytes per second, and 20 users would make this less than a single KB per person. This means that any query that is done will end up being as long in seconds as it is in size of kilobytes. Having worked for a major grocery retailer for many years, we ran these circuits to our stores, but ended up going to 256 or 512 because common web applications needed more space, and we have to utilize QoS very carefully to protect EFT and financial transactions of the customers. I would guess you have a bandwidth issue, but you'd need to provide additional information.

You need to profile the application to determine what is a suitable bandwidth. By running a packet capture like Ethereal / Wireshark between the client and server you can determine how much data is returned by individual transactions. With that value you can calculate how much bandwidth is necessary to achieve acceptable user response times.

BernieM

You also need to consider the effect that the distance netween the offices may have. For some applications even a few hundred miles can make a big difference, A few thousand miles renders many applciations useless.

The key here is the number of network level request/response pairs per user operation. If it is say 100 and the two machines are 3000 miles apart then each user operation will take about

100 x 0.1 second or 10 seconds. This is likely to be unnaceptable.

The Round Trip Time between New York and London is about 0.070 seconds but can be more if a less direct route is used.

Yes, all the turns in a transaction being affected by propagation delay and other delays which form the overall latency of wan links and long distance data transmission generally do take their toll on user response times. Unfortunately 'bandwidth' is often mistakenly named as the culprit for poor response when there are many other factors to consider. Some inhouse apps just aren't designed for wan use. We once had a scanning project in the pipeline and had a serious look at 'wan acceleration' technologies like those in Riverbed products and say some very impressive results. Having a look at the technology of products like these gives a better understanding of issues associated with delivering apps across a wan.

formatting link

Join the Discussion

Have something to add? Share your thoughts — no account required.

Didn't find your answer?

Ask the community — no account required