Hi all.
we have a .net 2.0 web service written C#. It is deployed on an IIS 6.0 running on Windows Server 2003. The web service offers two methods:
1. retrieve a file of a given size, which can be controlled by a parameter
2. log a time span to a csv file residing on the server
We consume these methods on a site in Asia, whereas the server resides in Europe. The idea is to request files from different sizes via method (1) and log the time it took to retrieve these files by method (2). A powershell script performs this every ten minutes. In the end, we get a kind of network monitor plotting transfer rates from Europe to Asia.
All of this stuff works and produces the results we are interested in. The part we do not understand is the following: we retrieve a file of about 100k, then 1000k, then 5000k, every ten minutes. First we observed a horrible performance impact for the 5000k file, receiving transfer rates of about 1/10th of the transfer rate for the 1000k file. Further tests revealed that it is not the file itself causing the problems. In fact, when changing the order of the file downloads, e.g. first 5000k, then 1000k, then 100k, performance drops always for the third of the three files.
If, for logging the results, we do not use method (2), but log the same information locally on the Asia client consuming the web service, this does not happen, and we get comparable results for the different file sizes. However, of course we only measure the time for calling method (1). So it seems that calling method (2) has a performance impact on a later call to method (1), although there is no dependency of the two methods in the source code.
Performing the very same procedure locally on the server does not show this behaviour. Calling (2) does not seem to have an impact on calling (1). For every other consumer but the local host, the behaviour is as described for the Asia client.
We have no idea why this happens. Any clues? We suspect that there is a flaw in our IIS config. What do you think?
Note: the web service has its own app pool configured, with 4 worker threads, where we never consumed the web service from more than 4 sites at once.