Why Getting Http Request and Response too late

Question

I am using http post method to send request to a Http Server URL.

Time difference between request and response is around 60 seconds but as per Server team they are sending response withing 7 seconds once request reached at their end.

I don't think network is taking remaining 53 seconds of time to reach packet at server end, so what can be the issue.

In this application we are using synchronous communication in between client and server. Kindly provide me following details also.

1. Is it due to server is sending request at more speed than server is able to handle. In this case many times client is getting request at interval of 3 seconds whereas server is taking 7 seconds to handle this.
2. What is network buffer. Whether there are two buffers at network level one at client place and other at server place.
3. If server is unable to handle request at same speed what client is sending is all request get buffered at client buffer and what will happen if more request are pending to be processed than maximum size of that buffer.
4. What are alternative way to improve performance if we are at client end and no control on server

EDIT : When I used wireshark in my network to capture network logs I found that it is appearning in wireshark 20 seconds after actually my application is send to Server. What is reason behind this delay. what can be the possible reason in which request is appearing in network 20 seconds delay from actually it has been sent.

Answer 1

In regards to your edit, to help you understand. Networking follows a model called Open Source Intercommunication (OSI). This model is broken down into seven distinct layers, all with a function.

Those layers are here:

Wireshark detects packets which are located at Layer 3. Which is handled by a Router. The Network Interface Card (NIC) takes the allotted data and turns it into a packet to send across the wire.

Wireshark won't detect the packet until your NIC has converted it into a packet in which a Router handles.

You see once it is converted into a packet it contains the following information:

• 4 Bits that contain the version (IPV4 or IPV6)
• 4 Bits that contain the Internet Header.
• 8 Bits that contain the Type Of Service or the Quality Of Service and priority.
• 16 Bits that contain the length of the packet in Bytes.
• 16 Bits that contain the identification tag to help Reconstruct the packet from Fragments.
• 3 Bits, the first is a zero followed by a flag that says to allow Fragment or Not. And quantity.
• 13 Bits that contain the Fragment offset, field to identify the position to original.
• 8 Bits that contain the Time To Live (TTL) and Hops across Routers.
• 8 Bits that contain the Protocol (TCP, UDP, ICMP, etc.)
• 16 Bits that contain the Header Checksum
• 32 Bits that contain the Source IP Address
• 32 Bits that contain the Destination IP Address

Those are the key 160 Bits that are created when creating such a packet.

What does this mean?

Well, you know that it takes twenty seconds for Wireshark to detect your packet. So right off the bat we know it took your application twenty seconds to actually build this packet.

Which we know the Server will also need to Reconstruct this packet so that it can handle the data and possibly send off a request.

We also know that the Router is acting like a traffic cop, sending your data across the internet or local network.

Well, that adds quite a bit of inference? But where do I go?

You have a utility called: tracert

On average it takes a route request one to two milliseconds to pass through five to six foot cable, so if it generates the initial hop one or two milliseconds, but the second hop is triggered in twenty-thirty milliseconds then you could use a simple formula:

6 * 20

Based on the current speed from our tracert we can estimate the time duration. This is a very generic approach but tools exists for exact accuracy. But the more hops, the more time it will take to reach the destination. Also the more you'll multiply.

What about that in between from Client to Server?

• Local Area Networks (LAN) : The internal efficiency of a network is due to the optimizations of each Network Protocol, Equipment, and Physical Median. A Network Administrator has to measure reliability with speed; as well as all the traffic generated by the Network. So an equipments throughput and physical median are important. You wouldn't want a ten cars merging into a one lane tunnel, that could create a bottle neck same applies for a Network.

• Wide Area Network (WAN) : This essentially is the connection to the Internet, the Cloud. Think of it like this: Your computer is on a LAN, the Router goes to a WAN. Then your ISP more then likely has a LAN which then has it's WAN open up to a larger distribution facility. It keeps working it's way up until it reaches the internet.

What can I do though?

You know what is in between now, but what can I do?

Well, when your generating your Service you obviously want to ensure your code is lean and highly efficient. As efficiency can be crucial in speed. So altering buffer sizes, transmission rates, and etc. can greatly improve your application.

Obviously good code practice will help.

My code is rock solid though?

If you believe your code isn't the problem at this point, or the method in which you Host and Create your Service then these factors may be the cause:

• Local Machine may be generating excessive chatter, so it takes quite a bit longer.
• Local Network is generating excessive chatter or inefficient / low throughput.
• Your request is traveling long distance, so the time is delayed.
• Your Internet Service Provider may have Hardware Firewalls, Proxies, and so on that scan these packets.
• Your Server may have excessive request or the Host method isn't efficient.

Those are a larger chunk of variables. All you can try is to refactor the Service and ensure your Server is hosting it the most efficient way possible. Otherwise you'll want to get a Information Technology Team involved it is critical.

But keep this in mind, your experience may be better or worst then another clients with interfacing with this service.

I'm speaking under the assumption your deployed in one location and you could be several states away from your Server.

Tools:

Command Line:

• Ping
• Tracert

Network and Protocol Analyzers:

• Fiddler (HTTP/HTTPS) : See if Fiddler displays any HTTP Status Codes for Troubleshooting.
• Wireshark : Will analyze your network traffic which can help time durations.

There are other utilities available to actually mitigate and test Network Speeds even to other locations, just Google "Network Tools". Fluke has a few.

Hopefully that explains why it may take twenty seconds for Wireshark to even display the packet on the Network.

Hope that helps.