mirror of
http://git.haproxy.org/git/haproxy.git/
synced 2024-12-24 13:42:16 +00:00
72d0dcda8e
The goal is to indicate how critical the allocation is, between the least one (growing an existing buffer ring) and the topmost one (boot time allocation for the life of the process). The 3 tcp-based muxes (h1, h2, fcgi) use a common allocation function to try to allocate otherwise subscribe. There's currently no distinction of direction nor part that tries to allocate, and this should be revisited to improve this situation, particularly when we consider that mux-h2 can reduce its Tx allocations if needed. For now, 4 main levels are planned, to translate how the data travels inside haproxy from a producer to a consumer: - MUX_RX: buffer used to receive data from the OS - SE_RX: buffer used to place a transformation of the RX data for a mux, or to produce a response for an applet - CHANNEL: the channel buffer for sync recv - MUX_TX: buffer used to transfer data from the channel to the outside, generally a mux but there can be a few specificities (e.g. http client's response buffer passed to the application, which also gets a transformation of the channel data). The other levels are a bit different in that they don't strictly need to allocate for the first two ones, or they're permanent for the last one (used by compression). |
||
---|---|---|
.. | ||
api | ||
acl.txt | ||
body-parsing.txt | ||
connect-status.txt | ||
connection-header.txt | ||
connection-scale.txt | ||
fd-migration.txt | ||
hashing.txt | ||
list.fig | ||
list.png | ||
listener-states.fig | ||
listener-states.png | ||
lua_socket.fig | ||
lua_socket.pdf | ||
muxes.fig | ||
muxes.pdf | ||
muxes.png | ||
muxes.svg | ||
notes-layers.txt | ||
notes-poll-connect.txt | ||
notes-pollhup.txt | ||
notes-polling.txt | ||
pattern.dia | ||
pattern.pdf | ||
polling-states.fig | ||
sched.fig | ||
sched.pdf | ||
sched.png | ||
sched.svg | ||
ssl_cert.dia | ||
stats-v2.txt | ||
stconn-close.txt | ||
stream-sock-states.fig |