Hi Lucas,
Le 10/01/2025 à 2:20 PM, Lucas Rolff a écrit :
I ended up trying to give SPOE a try, since it seemed like a possible contender
for this use case.
I tried to give the LUA, Python, Rust and Go examples a go, and it seems like I
need as many workers/threads on the agents, as I have concurrently processed
requests in haproxy.
I cannot say for Go and Rust SPOA, but I've checked the LUA/Python SPOA
(https://github.com/haproxy/spoa-server) and indeed, a worker is only able to
process a message at a time. In fact, there is exactly one connection per worker
that processes one message at a time. So it does not scale at all. It is more a
proof of concept than a production ready agent.
Whatever. To make it work, you must set a maxconn on your SPOA servers to not
open more connections than the agent can accept. In fact, I suggest to set a
slightly lower maxconn. For instance a maxconn set to 5 for 8 or 10 workers.
Because the maxconn is unfortunately not a so strict value than it should be.
Note that the SPOE was rewritten in 3.1. On older versions, the SPOP connexion
management is far from perfect. So if you really want to go with the SPOE, I
suggest to use the 3.1.
Is the expectation of SPOE, that the agents are fully event-driven as well, to
be able to handle the AGENT-HELLO frames coming from haproxy, and then get them
processed (within the processing timeout).
If that's the case, that obviously complicates the usage of SPOE a lot more
The SPOE does not expect anything special about the agents. But they must be
sized to handle the load. In this case, it is obvious the spoa-server will never
be able to handle many concurrent connections. And because it does not support
the "pipelining" mode, there is no way to multiplex the requests.
--
Christopher Faulet
