A: 

Chances are that because, in your test, you only call this once, the delay you see is the C# code being JIT compiled.

A better test would be to call this twice, and discard the timings from the first time and see if they are better.

An even better test would be to discard the first set of timings, and then run this many times and take an average, although for a very loose "indicative" view, this is probably not necessary.

As an aside, for this sort of timing, you are better off using the System.Diagnostics.Stopwatch class over System.DateTime.

[EDIT] Also, noting Mant101's suggestion about proxies, if the setting no proxy fails to resolve things, you may wish to set up Fiddler and set your request to use Fiddler as its proxy. This would allow you to intercept the actual http calls so you can get a better breakdown of the http call timings themselves from outside the framework.

Rob Levine
This is so wrong. (1) The method is JIT compiled before it is run, not halfway through it. (2) JIT compiling such a short method does not take 6 seconds. (3) The time it takes to get the timings is insignificant compared to 6 seconds. (4) You take averages when you're measuring short, time-critical operations that take milliseconds; not when communicating with an HTTP server takes 6 seconds. (5) While the accuracy of DateTime.Now is not as accurate as a Stopwatch, in the range of seconds the difference in accuracy is totally insignificant.
dtb
1) THIS method may be jitted before it is run, but you will notice it calls other methods. It is *these* that may be jitted as this method progresses.2) The time it takes to JIT something is dependent on many things including current memory use (and the need to page out), disk speed, etc. Generally it is fast. Always? no.3) I never said it wasn't4) My point being - that if this slow experience was due to something like disk IO, averging may help reduce the impact. I was not talking about averaging to remove timing jitter. Your assumption, not mine.5) I said "as a general rule".
Rob Levine
Addendum to your point 4 - it is implicit in your phrasing that you feel the 6 seconds is due to communicating with the HTTP server. I am suggesting it may not be. You do average short-timecritical operations to reduce the impact of clock jitter and other random error sources. You *also* may do the same, to reduce the impact, on a computer, of your machine being busy performing other tasks that are not obvious at test time. It may well be worth running the same task again and again, possibly at different times, in order to eliminate impact of hidden scheduled or other tasks.
Rob Levine
Thanks for the stopwatch recommendation i'll look into it, as for the JIT it isn't that as I have done several calls to the same function one after the other and always get 5+ seconds and the system here is a fully fledged server with 6Gb ram built soley for development
Paramiliar
Yes - in that case you probably have eliminated the JITing as a cause.
Rob Levine
it would appear to be proxy, but how can I check if a proxy is setup before sending the transmission, and if no proxy is setup then set it to null
Paramiliar
You'll need to examine HttpWebRequest.Proxy to see if a proxy is set, but *do* read the documentation because I can't remmeber the exact details: http://msdn.microsoft.com/en-us/library/system.net.httpwebrequest.proxy%28VS.90%29.aspxIIRC, the request will use the default proxy (as in the IE proxy) if defined, unless you override it to use another, or to use none.
Rob Levine
+2  A: 

Make sure you explicitly set the proxy property of the WebRequest to null or it will try to autodetect the proxy settings which can take some time.

Mant101
If its the case of proxies would I be better do a splash screen load and doing a blank call? the reason I ask is because the software is being used on multiple networks from laptops and some networks use proxies
Paramiliar