On 9 December 2016 at 20:07, Apollon Oikonomopoulos <[email protected]> wrote: > Hi Pavlos, > > On 17:31 Fri 09 Dec , Pavlos Parissis wrote: >> On 09/12/2016 08:54 πμ, Apollon Oikonomopoulos wrote: >> > Hi Willy, Elias, >> > >> > On 08:33 Fri 09 Dec , Willy Tarreau wrote: >> >> On Thu, Dec 01, 2016 at 02:53:25PM +0100, Elias Abacioglu wrote: >> >>> # Should I use core 0 on each CPU for backends (proc 1+15) or should >> >>> I >> >>> use core 1(proc 2+16)? >> >> >> >> Backends are processed on the same CPU as the frontend which passes them >> >> the traffic, so the bind-process has no effect there. In fact bind-process >> >> on a backend means "at least on these processes". >> >> >> >> That's why it's better to proceed like this (stupid numbers, just so that >> >> you get the idea): >> >> >> >> listen ssl-offload >> >> bind-proess 2-50 >> >> bind :443 ssl .... process 2 >> >> ... >> >> bind :443 ssl .... process 50 >> > >> > I wonder if a `per-process' keyword would make sense here. I find >> > >> > bind :443 ssl .... per-process >> > >> > more concise than 15 or 20 individual bind lines. This would have the >> > same effect as N bind lines, one for each process in the bind-process >> > list. >> >> If you have bind per process then all sockets are bound separately and you >> get X listening sockets on port 443, which results to have one distinct >> socket >> in each process with its own queue(SYN backlog queues and etc), and the >> kernel's >> load balancing works much better. > > That's true, yes. However what I'm saying is that some syntactic sugar > to have the parser auto-expand a single "bind" directive to create N > sockets instead of one, would be nice. >
Indeed, that would be nice. I guess it isn't big issue as most of the people use a configuration management tool, which does the expansion. Cheers, Pavlos
