Comment 13 for bug 405251

Frits Jalvingh wrote:
[...]
> between. What is remarkable in this log is the huge amount of "xxxx byte part
> read" messages (39900 lines!!) taking a long time in all; if every message
> here also means a full round trip to the server this at least explains the bad
> performance here (end-to-end ack delay).

Each of those lines corresponds to a single record in bzr's database,
more or less. There isn't a full round trip to receive each one, the server
simply streams them to client continuously. (You should be able to verify this
with tcpdump or similar pretty easily, if you're curious.)

The number of these lines indicates that there's either a lot of revisions
(possibly merged revisions), a lot of new file versions, or both. The size of
some of the byte parts (e.g. 681544) indicates that there have been some very
large files added (or very large modifications to files) somewhere in the
history.

> What is also strange is that it starts doing that after 113 seconds; what is
> it doing before that!?

The server is figuring out what to stream, basically. This phase should be
faster (and there are bugs and changes in progress to address that), but for
such large streams it's pretty common for this to take a couple of minutes.
This is another symptom of whatever causing such large transfers in the first
place.

-Andrew.