Remove disabled StreamSocket::checkRemoval criteria minimum throughput

[sgothel]

Change-Id: I9212cdf8b87c1c7b0df5761db956cbaa4fd44f58

• Resolves: Handle limited open Connections due to keepalive connections (cool#9621) #9833 refining PR Handle limited open Connections due to keepalive connections #9916
• Target version: master

Summary

PR #9916 added MinBytesPerSec minimum throughput criteria for checkRemoval to limit connections, i.e. cleaning up unresponsiveness or lagging sockets.

Due to its unreliable nature per request, the criteria has been disabled per default but remained in the code test w/ UT UnitTimeoutSocket.

Turns out that even the UT may fail on certain test setups.

We decided to remove this criteria altogether, as it will nor be used.

Checklist

• I have run make prettier-write and formatted the code.
• All commits have Change-Id
• I have run tests with make check
• I have issued make run and manually verified that everything looks okay
• Documentation (manuals or wiki) has been updated or is not required

[Ashod]

Thanks, @sgothel. Less code is more reliable code.

[mmeeks]

Looks sensible to me - I was really unsure why that was there in the 1st place - was this based on some research of some other server that does this.

Also - we should consider not dis-connecting sockets that still have live requests being processed - and/or/particularly those with un-sent data in the output socket-buffer.

[sgothel]

Looks sensible to me - I was really unsure why that was there in the 1st place - was this based on some research of some other server that does this.

It was one of your ideas in #9833, see #9833 (comment)

Also - we should consider not dis-connecting sockets that still have live requests being processed - and/or/particularly those with un-sent data in the output socket-buffer.

Then I shall add another PR, not hard closeConnection(), but rather leaving it up to the _shutdownSignalled instrument in StreamSocket via its shutdown() only. Will do.
(Edit: Address with #10326)

[mmeeks]

Ah ! =) so slow-DOS prevention; worth reading how other proxies & web servers handle this - makes sense in the abstract of course.

[sgothel]

Ah ! =) so slow-DOS prevention; worth reading how other proxies & web servers handle this - makes sense in the abstract of course.

Yup, could re-add this - however, would need a well average-throughput statistical fancy working method.

While the removed throughput was an average, it should have been skipped for some initial time at least
and also would need heavy testing etc.

I did the relaxed ping lag average on the WSPing though .. which seems to be OK.

[Ashod]

A threshold for open sockets is a good starting point. Only when we are above it do we need to see which sockets are slow/unresponsive and remove them. With a sensible threshold (ideally configurable), this should be safe while being defensive (when needed).