[ZODB-Dev] zeo2a1 performance cold spots

[Toby Dickenson]

On Sunday 30 Jun 2002 2:18 am, Jeremy Hylton wrote:

> It is definitely more efficient to do "".join(output) than to repeatedl=
y
> concatenate.  Each concatenate creates a new string and copies the cont=
ents
> of the old strings into it, which has quadratic cost.

It is quadratic on the number of strings appended. For ZEO that number is=
=20
always small, and almost always 2. I think the simpler code has an advant=
age.

> Also, why limit it to 16384?  Is that the TCP default buffer size?  I'd
> rather let send() decide how many bytes it can buffer than choose an
> arbitrary limit.

Its not *limited* to 16k. If one single message is larger than 16k then i=
t=20
will still submit the whole message to TCP. This is by far the most commo=
n=20
case given ZEO's challenge-response protocol.

The 16k threshold is there as a cheap way of avoiding bad effects of the=20
quadratic behaviour. As a worst case, appending small strings up to 16k i=
s=20
still 'fast enough' (and I dont think ZEO will ever exercise that worst c=
ase)

> I'd also like to omit the TCP_NODELAY for now, as it's generally consid=
ered
> a measure of last resort.

Generally, yes. But what specific problems can it can cause for ZEO?

>  What kind of performance difference do you see?

The test was over localhost interface, starting with an empty client cach=
e,=20
render a Zope page which queries several large Btrees and performs severa=
l=20
other calculations. This needs to zeoLoad a few 100s of objects. Original=
ly=20
the request took 7s, either patch reduces it to under 2s. tcpdump shows a=
=20
delay of 34ms in almost every response.=20

> The other effect you were seeing, BTW, is that TCP delays ACKs in hopes=
 of
> piggybacking the ACK on a packet with data in it.  The ACK can be delay=
ed
> as long as 200ms; at that point, the stack will send an ACK even if it =
has
> no data to send.  This can lead to bad effects for an RPC system. The R=
PC
> request takes more than one packet.  If the Nagle algorithm delays the =
last
> packet then the ACK will also be delayed, because the receiver won't se=
nd
> any response data until the entire message has been procssed.

It sounds like you are arguing _against_ leaving Nagle enabled in ZEO.