Le jeudi 27 mai 2010 à 12:35 +0200, Maciej Żenczykowski a écrit : > You could split it into a tree if you really really cared... > > --- > > But, if you put the 48 rules in a chain which only deals with incoming > new connections then it only triggers on the initial syn and > connection tracking deals with the rest (at least if you use the > mangle table to mark, and nat table to REDIRECT -- don't know about > TPROXY). Somebody setting up 48 squid instances must care about performance, or something is wrong... I would expect maybe 10.000 new connections per second for such a setup ? I personnally would use RPS (Remote Packet Steering) to distribute the load on all available cpus, and one squid per available cpu too. TPROXY selection would then use a match on selected CPU echo ff >/sys/class/net/eth0/queues/rx-0/rps_cpus -A extrachain -m cpu 0 -j TPROXY --tproxy-mark 0x01/0xff --on-port 3127 -A extrachain -m cpu 1 -j TPROXY --tproxy-mark 0x01/0xff --on-port 3128 -A extrachain -m cpu 2 -j TPROXY --tproxy-mark 0x01/0xff --on-port 3129 -A extrachain -m cpu 3 -j TPROXY --tproxy-mark 0x01/0xff --on-port 3130 -A extrachain -m cpu 4 -j TPROXY --tproxy-mark 0x01/0xff --on-port 3131 -A extrachain -m cpu 5 -j TPROXY --tproxy-mark 0x01/0xff --on-port 3132 -A extrachain -m cpu 6 -j TPROXY --tproxy-mark 0x01/0xff --on-port 3133 -A extrachain -m cpu 7 -j TPROXY --tproxy-mark 0x01/0xff --on-port 3134 -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
