Hi,
As with UDP workers, the kernel divides incoming TCP in a semi-random way at a trough of TCP workers all calling accept(). So, the distribution is indeed at the connection level rather than the message level, and so long as the connection persists, messages go to the same worker.
In theory, at sufficiently large values of N, this shouldn't be a problem since an approximately equal number of TCP connections will be allocated to each worker. Or are your expensive crypto workloads distributed in a very lopsided way that doesn't touch all TCP clients approximately equally in the grand scheme of things?
If you're really concerned about it, though:
On Fri, Feb 23, 2018 at 06:00:22PM +0000, Cody Herzog wrote:
Perhaps the ASYNC module might work for my needs. It seems like I could use async_task_route() to divide certain messages evenly amongst the async workers.
This sounds like a reasonable solution.
-- Alex