Remove unnecessary write_avail causing extra block allocations for h2

[shinrich]

Using @bryancall's proxy.config.res_track_memory feature to figure out buffer allocations, it showed that the buffer set up by HttpSM::setup_server_transfer had over 2000 allocations for a H2 transfer of 10MB but only 600 allocations for the same transfer over H1.

This code change, reduced the number of allocations to around 1000 for H2. Still higher than H1, but much better.

The write_avail will never return 0 and always allocate a new block if the current writer block is full. So the if return should never trigger. In the H2 logic, we are copying IOBlocks from the origin side MIOBuffer, so the empty block will never be used. Could explain why we started seeing unusually long buffer block chains.

[masaori335]

MIOBuffer::write_avail() is tricky especially when water_mark is set. I agree with some IOBlock allocations are wasted.

The write_avail will never return 0 and always allocate a new block if the current writer block is full. So the if return should never trigger.

From my understanding, this is not accurate.

• the block size & warter_mark of this MIOBuffer are 32KB (assuming default config)
• when the current writer block is full (max_read_avail() returns more than 32KB)
• high_water() returns 1 and current_write_avail() returns 0
• check_add_block() do nothing
• write_avail() returns 0

This scenario could happen when Http2Stream is not the only consumer of HttpTunnel (e.g. "cache write").

[masaori335]

We need more investigation about MIOBuffer::write_avail() with water_mark.

[masaori335]

This change is definitely good. We should not call functions in Debug that have a side effect.

[zwoop]

@vmamidi Can you look at this please.

[shinrich]

I think PR #5903 has address this issue. Closing.