 | |
== Why there is a huge jump in the time used? ==
Dotnet Framework (Performance) microsoft.public.dotnet.framework.performance
 |
| | Thread Tools | Search this Thread | Display Modes |
#11
 
| |||
| |||
|
Re: == Why there is a huge jump in the time used? == -
12-18-2005
, 11:56 AM
|
hmm.. im not really familiar with the readtoend() method but something else my be creating unnecessary allocations. try setting the initial string returnString = null; you might also want to try something like this to avoid the string allocation. try{ open file here return fs.ReadToEnd(); }finally{ fs.close(); } if this code is really important, you may want to hold the file in memory. there are alot if factors that come into play when you are doing IO in this manner that may be out of your immediate control. i wouldnt go any further without caching this file.. is that an option? |
likely to me that the overhead is in the webservice stuff, not in the
reading of the file. Maybe IIS handles large responses from webservices
(seems to be >= 32K, the 30KB response string + headers) differently.
Just guessing. But 100ms would be too much even for 1MB, and not 30KB.
HTH,
Stefan
#12
| |||
| |||
|
|
I would try benchmarking the file operation itself separately, it seems likely to me that the overhead is in the webservice stuff, not in the reading of the file. Maybe IIS handles large responses from webservices (seems to be >= 32K, the 30KB response string + headers) differently. Just guessing. But 100ms would be too much even for 1MB, and not 30KB. .... |
Yes, just now I realized that OP measures time at the *client*, not the
server. Even without IIS, sending larger amout of data over socket would
require round trips. This is tricky to exactly calculate, it would depend on
max. window size, congestion avoidance algorithm used etc. For example, if
you send 16K, it may fit in initial window, so is transmitted without much
delay. However, sending more may require waiting for other side to
acknowledge the data (to open TCP send window). Since fast networks are more
limited by latency than throughput, I would expect such behaviour. It should
stabilize at large file sizes, if TCP window is big enaugh (TCP big window
option enabled). Rule of thumb is that window size must be > bandwith * RTT
(Round Trip Time). Some info is on:
Regards,
Goran
#13
| |||
| |||
|
|
.... (Round Trip Time). Some info is on: |
I hate when I accidently click 'send'...
Goran
#14
| |||
| |||
|
|
"Stefan Simek" <simek.nospam (AT) triaxis (DOT) nospam.sk> wrote in message news:O8uuJQ$AGHA.3064 (AT) TK2MSFTNGP10 (DOT) phx.gbl... .... I would try benchmarking the file operation itself separately, it seems likely to me that the overhead is in the webservice stuff, not in the reading of the file. Maybe IIS handles large responses from webservices (seems to be >= 32K, the 30KB response string + headers) differently. Just guessing. But 100ms would be too much even for 1MB, and not 30KB. .... Yes, just now I realized that OP measures time at the *client*, not the server. Even without IIS, sending larger amout of data over socket would require round trips. This is tricky to exactly calculate, it would depend on max. window size, congestion avoidance algorithm used etc. For example, if you send 16K, it may fit in initial window, so is transmitted without much delay. However, sending more may require waiting for other side to acknowledge the data (to open TCP send window). Since fast networks are more limited by latency than throughput, I would expect such behaviour. It should stabilize at large file sizes, if TCP window is big enaugh (TCP big window option enabled). Rule of thumb is that window size must be > bandwith * RTT (Round Trip Time). Some info is on: Regards, Goran |
#15
| |||
| |||
|
#16
| |||
| |||
|
|
Hi all, Thank you very much for your help! Actually, if you look into my original post, you will see 90% measurements for 32K file are greater than 100ms, but there are still some of them (10%) are just 10-20ms. Can we use max. sending window size to explain this? Also, do you know if there is a way to change the initial window size? (Is this part of TCP protocol itself?) .... |
Depends on you ping times. 100 difference is too big for local area
networks, where ping times are around few ms. As few other posters
suggested, you have to break problem down to few things (measure): loading
file from disk, IIS overhead, network overhead. For measuring network
overhead, you may found etheral tool usefull (packet caputure tool, free),
though you'll need some considerable knowledge about TCP/IP protocol to
interpret result correctly (it is non-trivial task). If you are running
tests over LAN, my educated guess would be that most overhead comes from
IIS.
Regards,
Goran
|
« Previous Thread
|
Next Thread »
| Thread Tools | Search this Thread |
| Display Modes | |
Linear Mode
| |
Powered by vBulletin Version 3.5.4
Copyright ©2000 - 2008, Jelsoft Enterprises Ltd.
Copyright ©2000 - 2008, Jelsoft Enterprises Ltd.