Evgeny Kotkov <[email protected]> writes: > When I tried the same with 100% CPU load on the target server, I got the > following results. The numbers aren't exactly stable, but, again, I cannot > say that I see the difference: > > Unpatched: 959 ms 189 ms 162 ms 290 ms 306 ms 808 ms 316 ms 634 ms > Patched: 560 ms 773 ms 410 ms 242 ms 191 ms 262 ms 472 ms 987 ms
Do you know what you are trying to measure? How long does the httpd buffer take to fill on that server? 100% CPU load is not enough. Under no load httpd on my server fills its buffer in about 20ms. With another process using 100% CPU the OS scheduler would still give half the machine to httpd, perhaps doubling the time to fill the buffer. The patch causes the first results to get sent earlier saving ten or twenty ms. How do you expect to see that on your server where the timing varies by far more? You have to load the server (CPU, memory bandwith, CPU cache, FSFS cache, etc.) until you can see the time taken to fill the apache buffer. Run a log that returns lots of revisions and load the server until you can see the client receiving the data in chunks separated in time. With your network latency variation you are going to need to load the server until the chunks are several seconds apart. In my case I loaded the server until the buffer takes 800-1000ms to fill. > Sorry, guys, but based on these observations, I am going to keep my current > vote unchanged. I showed a reduction from about 1000ms to 10ms but you still need to vote -0.5. It seems you do not believe me :-( -- Philip Martin | Subversion Committer WANdisco // *Non-Stop Data*
