How To Measure Webservices Turnaround Between 2 Servers

Posted on 2014-01-13
Last Modified: 2014-01-14
I have a site that uses webservices and I need to measure server turnaround.   I am doing this because the host we have now is too slow and I don't want to go to a different host unless it is an improvement.  

I want to measure how long it is taking to return a specific size packet that is being transmitted from our site to our vendors site.  I then want to measure the same response time from a different host that I am considering switching to.  This server would do the same thing and send the same size packet to our vendor too.

Currently, my host is HostGator.


Question by:sharingsunshine
  • 7
  • 4
LVL 34

Expert Comment

ID: 39779587
1. Use ping to test the response time between any two computers/servers.

2. Your problem is PROBABLY not network speed, though. Most large hosts have a pretty good data pipe to support their users, so switching from one like HostGator isn't likely to improve speed.

3. USUALLY if a web site is slow, it is because of something on the site itself (slow queries, large sites, unoptimized content, etc...). One way to test this is to create a simple HTML page that simply says "Hello world". After you create the page, visit it in your browser and see how long it takes to show up. If it's still slow, try asking someone else to also try visiting it in their browser and see if it's still slow. Usually it will come back pretty fast because it's just delivering static content.

If your HTML page still comes back really slow, there's always a slim chance that you're on a shared server with too many people. You can ask HostGator to switch to another one of their servers.

Author Comment

ID: 39779603
We have a dedicated server, sorry I didn't make that clear.  

I thought ping just tested between my desktop and whatever ip or domain name I was trying to contact?  How would I do between the 2 servers?

I was thinking the slowness was based on how many hops to the internet.  Am I wrong in wondering that?
LVL 34

Accepted Solution

gr8gonzo earned 500 total points
ID: 39779727
Ping can test between any two computers. So if you log into your server and run a ping from there to the other server, that will tell you the response time.

Questions about speed are always a bit tricky because there can be so many causes, and it's usually never a black-and-white answer. If you request a web page from a server, it has these components:

1. The browser does a DNS lookup to translate the domain into an IP
2. The browser establishes a socket connection to the server IP (the network hops)
3. The browser and server do a handshake (in case of things like SSL)
4. The browser sends the initial request to the web server ("give me the web page named x.html")
5. The web server processes the request (and if it's a PHP page, hands the request off to PHP to process)
6. In case of PHP, it processes the request completely (database queries and all that) and hands the finished output to the web server
7. The web server sends the output back to the browser
8. The browser receives the HTML / output / content
9. The browser renders the HTML into visual elements so you can see what the page looks like.
10. If the HTML has any additional pieces of content, like images or javascript, the browser repeats steps 1-8 for each piece (usually up to 2 at a time per domain).

Now, that said, #1 is almost always cached, so it takes a couple of milliseconds each time.
#2 usually takes a couple hundred milliseconds.
#3 usually takes ~100 ms,
#4 takes a couple of milliseconds,
#5 takes ~100ms,
#6 takes any amount of time between a few milliseconds up to several seconds,
#7 and #8 depends on the server and client bandwidth and the amount of data to download, but it's usually in the milliseconds.
#9 depends on the complexity of the HTML. Heavy pages will take more time but this is more dependent on the visitor's CPU than bandwidth.

ANY step has the POTENTIAL to make the whole process slow, but once something is configured properly, it typically has the above flow (or faster). Nine times out of ten, speed problems are the result of step 6, because there is some processing step that simply takes too long. Inefficient code, slow database queries, etc...
Master Your Team's Linux and Cloud Stack

Come see why top tech companies like Mailchimp and Media Temple use Linux Academy to build their employee training programs.

LVL 34

Expert Comment

ID: 39779748
Also, a few notes:

1. The above is an approximation, not an exact breakdown. The exact breakdown requires a bit more analysis and deeper understanding of all the pieces involved.

2. Item #2 also depends on geographic distance. If you're in the United States and you're trying to access a web page hosted on a server in India (or vice versa), you ARE going to experience slowdown due to network hops. Pretty much any time a network connection has to cross a large ocean, it's going to be a bit slower. But pretty much any land-based connections (even larger distances, like going from North America to South America or vice versa), are going to be pretty fast connections.

The underlying data pipes today are massive things. Your web page request is like a tiny goldfish swimming in a gulf stream with hundreds of whales. So unless you have some SERIOUS geographic discrepancies, changing hosts is going to be like your goldfish moving to a new position in the same gulf stream.

Author Comment

ID: 39779876
the two locations are in the US but it is now taking at least 2 -3 minutes to receive back the packet we send them through webservices.  So any improvement will help greatly.

The ping isn't being recognized.  By the way, the ping will only show what my current server to the vendor time is.  I need to know what the proposed server to the vendor time is too.

LVL 34

Expert Comment

ID: 39779974
Actually, ping should indicate the round trip (it's called "ping" because of "ping-pong", implying the return trip). If the ping (an ICMP network packet) hits a firewall or something that causes it to drop instead of being returned, it'll just seem to time out (which sounds like what is happening).

If you want to understand the ping time between you and any given hop between you and the destination server, you can perform a traceroute which will give you those details.

That said, if the two locations are in the US, I can all but guarantee that there's absolutely NO reason that you should ever see a network hop delay of 2-3 minutes. If there is a delay of that amount on ANY hop, it means that there's a malfunctioning network switch somewhere. That said, if there was a delay like that during transmission, it would probably result in a complete failure, not in just a delay.

That kind of delay is almost certainly due to the processing time (the step 6 I mentioned earlier). If you don't trust me and really want to give it a raw test, install a telnet client on your server. Then in that telnet client, connect to the destination server's IP on port 80.

Different telnet clients act differently, but usually you can tell once the connection is established and it's waiting for your input (usually it's a blank screen with a blinking cursor). Once you have that blinking cursor, you have passed the point where the network hops make a difference.

Then type:
GET /index.html HTTP/1.1<hit Enter>
Host:<hit Enter>
<hit Enter>
<hit Enter>

Open in new window

That will trigger step 4. It's the HTTP protocol that basically says, "Give me the page at"

That should give you either a valid HTML page or an error HTML page. Either one will tell you how fast the destination server CAN respond.

But if you give the destination server a really hefty request (e.g. a web service request to download two years of stock price history), then it's going to take that web service some time to gather the data and assemble it (could even be up to 2-3 minutes). Again, changing your web host will not change this.

It would be like trying to change cars in order to reduce the amount of time to get food from a drive through. It doesn't matter what car you drive - it still takes a minute to heat up a hamburger.
LVL 34

Expert Comment

ID: 39779984
Please bear in mind that I have no reason to tell you something that's not true. I have no affiliation with HostGator or anything. I'm just trying to save you from the headache and cost of switching to another host only to discover that you're still getting 2-3 minute response times.
LVL 34

Expert Comment

ID: 39779990
I would suggest you complain to your vendor about the long processing times, by the way.

Author Comment

ID: 39780169
We have mentioned it to the vendor but they haven't been able to change it or may not have had the resources allocated yet.

I have found that I can change my uplink connection (250 mb/s) to either 750 mb/s or 1GB .  In your opinion would I see much improvement?

So am I understanding correctly, there isn't anything that I can use that will measure response time from another server company like and my vendor?  Arvixe is just a hosting company I am considering.

It never even crossed my mind that you could be affiliated with any vendor.  So no worries!
LVL 34

Expert Comment

ID: 39780190
I don't think you would see an improvement unless you're uploading or downloading a TON of data (gigabytes). A 250 mb/s uplink is quite fast already, and the downstream speed is typically the same or faster, so you're probably fine with what you have.

You can do a traceroute to watch the individual hops that go from you to the destination server. The final hop will likely time out (since it doesn't respond to ping), but you should be able to see the ping time for the next-to-last hop, which should give you a pretty good idea of the time.

I'm not a gambling man, but I'd put $50 down that it's the vendor's problem, not yours nor your hosting company's problem. Maybe look for an alternate vendor or maybe open up another question on EE about the details of the service being provided by the vendor and what you're sending/receiving to see if there's a better way to do it?

Author Closing Comment

ID: 39780196
Thanks for the help.

Featured Post

PRTG Network Monitor: Intuitive Network Monitoring

Network Monitoring is essential to ensure that computer systems and network devices are running. Use PRTG to monitor LANs, servers, websites, applications and devices, bandwidth, virtual environments, remote systems, IoT, and many more. PRTG is easy to set up & use.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Suggested Solutions

Hi, in this article I'm going to teach you how to run your own site, and how to let people in (without IP). I'll talk about and explain each step... :) By the way, everything in this Tutorial is completely free and legal. This article is for …
Note: for this to work properly you need to use a Cross-Over network cable. 1. Connect both servers S1 and S2 on the second network slots respectively. Note that you can use the 1st slots but usually these would be occupied by the Service Provide…
Here's a very brief overview of the methods PRTG Network Monitor ( offers for monitoring bandwidth, to help you decide which methods you´d like to investigate in more detail.  The methods are covered in more detail in o…
This video gives you a great overview about bandwidth monitoring with SNMP and WMI with our network monitoring solution PRTG Network Monitor ( If you're looking for how to monitor bandwidth using netflow or packet s…

808 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question