[ZODB-Dev] zeo2a1 performance cold spots
Toby Dickenson
tdickenson@geminidataloggers.com
Mon, 1 Jul 2002 09:41:43 +0100
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.