The situation:

  • There is a remote server.
  • I am running a client program that makes calls to the server and requests data.
  • These requests perform very slowly.
  • The server limits the number of results to 50, and paginates the rest. So if there are 300 total results, I have to make a total of 6 separate requests.
  • (Per James' comment) The data is in JSON text format.
  • (Per James' other comment) The connection is an https (SSL) connection.

The owner of the server has offered to increase the number of results per page so that I can make fewer requests.

While I think this will help, I am worried that it still won't make the transaction fast enough for my purposes. I wonder: What if the problem is not the server's overhead for retrieving data? What if the biggest hit to performance is due to network bandwidth and latency?

How would I figure this out? I don't have access to the server at all. Let's say that a request takes 3 seconds to complete. Then:

  1. What portion of that 3 seconds is spent opening the TCP connection?
  2. What portion is spent sending the request data?
  3. What portion is spent waiting for the server to retrieve the data?
  4. What portion is spent waiting for all of the requested data to arrive at my machine?

I don't really want to have to roll my own TCP/IP code to get the low-level access needed to measure things like this.

I'm sure there have to be tools written for this. As I Google around, I see programs like netstat, ss, netperf, ttcp, etc. But I'm not even sure what words to use in a Google search to look for solutions to this problem.

Any ideas?

  • 1
    Suppose it depends on what the data is you are requesting - if returning json text then probably not bandwidth limiting and more processing constraints at server end. Whilst it might not be a complete solution, something like Wireshark (wireshark.org) will help you monitor network traffic and log packets in order. You could then compare timestamps on them to see which section of the process is taking most time? – James May 2 '13 at 21:54
  • It is returning JSON text. I'll update the post to reflect that. Packet capture in Wireshark is a good idea. I'll give that a try. – Aaron Johnson May 2 '13 at 21:58
  • Oh and I'd also add that negotiating a SSL handshake will undoubtedly cause an overhead with each request. You don't state whether this is http:// or https:// – James May 2 '13 at 22:06
  • Good point. https. I'll update the question to reflect that as well. – Aaron Johnson May 2 '13 at 22:08
  • In which case reducing the number of requests and increasing result set for each might have a material impact – James May 2 '13 at 22:10

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.