[pgpool-hackers: 3245] select(2) storm

[Jesper Pedersen]

Hi,

As noted in [1] a big percentage of the run-time is spent in select(2), 
which is known to have a performance overhead.

Attached is a "proxy" which replicates the scenario where pool_read*() 
calls pool_check_fd() showing the select(2) issue.

However, if we extended pgpool with a "state machine" which keeps track of

1) In which "direction" to read from, and hence write to
2) Known states where we need to change "direction"

we should see a sizable speedup. If proxy.c is compiled with 
-DSTATE_MACHINE I see a 20%-50% performance improvement. I tested with 
the various pgbench scenarios; -M simple, -M extended, ...

The "state machine" just keep track of the last client message, and last 
server message seen in order to "pair" them - f.ex. P -> 1, B -> 2 and 
so on.

The proxy binds to port 9999 and delegates to localhost:5432.

Standard caveat as this is mostly a hack :)

Comments ?

[1]  http://www.sraoss.jp/pipermail/pgpool-hackers/2019-February/003235.html

Best regards,
  Jesper
-------------- next part --------------
A non-text attachment was scrubbed...
Name: proxy.c
Type: text/x-csrc
Size: 10333 bytes
Desc: not available
URL: <http://www.sraoss.jp/pipermail/pgpool-hackers/attachments/20190218/ffd50a2f/attachment.bin>