Calculating Throughput for a Webservice download

Question

I have a client server application which exchanges XML documents for data requested by the client. Essentially the user enters some search constraints (attributes to match) and the client communicates with two systems to get data back (some data from a database and some data from file servers).

The data returned from the file servers (files of archived data) are quite a bit bigger than the metadata returned from the server, and correspondingly takes more time to perform.

The users have asked me to provide some metrics on how long it takes to download the archive data and the rate at which it is being downloaded (after the download).

The client server communicate with asyncronous I/O and numerous threads so I cannot just use a Start/Stop timer to accomplish this.

My current implementation works as such:

1. Record the current Ticks (this is a long running process so tick resolution is fine)
2. Hand off the request to the Webservice Asyncronously.
3. --- Wait ---
4. get the current ticks
5. get the size of the document returned (there is some overhead not accounted for from the SOAP envelope but this is ok, I think)
6. Rate = (Document Size / 1024) / (End Ticks - Start Ticks) * Ticks/Second (I let a timespan object do this)

At first I thought this method was ok, but I have user reporting that the rate is much lower for small samples than it is for large samples and that the rates vary a great deal over a single execution.

Is there a better way to calculate this rate that would be more immune to this? It makes sense that the rate will be greater for larger archives, but in testing I see it being 10-40x higher than for a file have the size, which doesnt make sense.

Answer 1

The throughput as measured in the question assumes the transfer time is homogenous. It is not. There is a setup cost at the beginning of the session that includes the TCP 3-way handshake and the server time required to produce the result. Once setup is complete, the rest is dominated mostly by the network throughput.

For large payloads, the setup time is a tiny fraction of the overall transfer time, and hence the calculated throughput approximates what you'd expect. For small payloads, the time measured is mostly setup time! As a result, the computed throughput could be off by orders of magnitude.

What can you do? Find a way to drop the setup components from the equation.

1. If you can get a notification when data starts arriving, you could start the tick count there. This should work for all but the shortest responses (where the content fits within a single network packet.)

2. Alternatively, have the server attach a timestamp to the response just before sending it. You could use that as the start time, taking care to adjust for any clock differences between the machines.