Re: svn commit: r1673919 - /subversion/branches/1.9.x/STATUS

Evgeny Kotkov <evgeny.kotkov_at_visualsvn.com> 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*