<p dir="ltr">At what point does buffer bloat set in?  I have a linux router with the below sysctl tweaks load balancing with haproxy to 2 squid instances.  I have 4 x 1Gb interfaces bonded and have bumped the ring buffers on RX and TX to 1024 on all interfaces.</p>
<p dir="ltr">The squid servers run with almost the same hardware and tweaks, except the ring buffers have only been bumped to 512.</p>
<p dir="ltr">DSL Reports has a speed test page that supposedly finds and quantifies buffer bloat and my setup does not introduce it, per their tests.</p>
<p dir="ltr">I am only running a home internet connection (50 down x 15 up) but have a wonderful browsing experience.  I imagine scale of bandwidth might be a factor, but have no idea where buffer bloat begins to set in.</p>
<p dir="ltr"># Favor low latency over high bandwidth<br>
net.ipv4.tcp_low_latency = 1</p>
<p dir="ltr"># Use the full range of ports.<br>
net.ipv4.ip_local_port_range = 1025 65535</p>
<p dir="ltr"># Maximum number of open files per process; default 1048576<br>
#fs.nr_open = 10000000</p>
<p dir="ltr"># Increase system file descriptor limit; default 402289<br>
fs.file-max = 100000</p>
<p dir="ltr"># Maximum number of requests queued to a listen socket; default 128<br>
net.core.somaxconn = 1024</p>
<p dir="ltr"># Maximum number of packets backlogged in the kernel; default 1000<br>
#net.core.netdev_max_backlog = 2000<br>
net.core.netdev_max_backlog = 4096</p>
<p dir="ltr"># Maximum number of outstanding syn requests allowed; default 128<br>
#net.ipv4.tcp_max_syn_backlog = 2048<br>
net.ipv4.tcp_max_syn_backlog = 16284</p>
<p dir="ltr"># Discourage Linux from swapping idle processes to disk (default = 60)<br>
#vm.swappiness = 10</p>
<p dir="ltr"># Increase Linux autotuning TCP buffer limits<br>
# Set max to 16MB for 1GE and 32M (33554432) or 54M (56623104) for 10GE<br>
# Don't set tcp_mem itself! Let the kernel scale it based on RAM.<br>
net.core.rmem_max = 16777216<br>
net.core.wmem_max = 16777216<br>
net.core.rmem_default = 16777216<br>
net.core.wmem_default = 16777216<br>
net.core.optmem_max = 40960<br>
net.ipv4.tcp_rmem = 4096 87380 16777216<br>
net.ipv4.tcp_wmem = 4096 65536 16777216</p>
<p dir="ltr"># Increase Linux autotuning UDP buffer limits<br>
net.ipv4.udp_mem = 4096 87380 16777216</p>
<p dir="ltr"># Make room for more TIME_WAIT sockets due to more clients,<br>
# and allow them to be reused if we run out of sockets<br>
# Also increase the max packet backlog<br>
net.core.netdev_max_backlog = 50000<br>
net.ipv4.tcp_max_syn_backlog = 30000<br>
net.ipv4.tcp_max_tw_buckets = 2000000<br>
net.ipv4.tcp_tw_reuse = 1<br>
net.ipv4.tcp_fin_timeout = 10</p>
<p dir="ltr"># Disable TCP slow start on idle connections<br>
net.ipv4.tcp_slow_start_after_idle = 0<br>
</p>
<div class="gmail_extra"><br><div class="gmail_quote">On Aug 4, 2016 2:17 AM, "Amos Jeffries" <<a href="mailto:squid3@treenet.co.nz">squid3@treenet.co.nz</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 4/08/2016 2:32 a.m., Heiler Bemerguy wrote:<br>
><br>
> I think it doesn't really matter how much squid sets its default buffer.<br>
> The linux kernel will upscale to the maximum set by the third option.<br>
> (and the TCP Window Size will follow that)<br>
><br>
> net.ipv4.tcp_wmem = 1024 32768 8388608<br>
> net.ipv4.tcp_rmem = 1024 32768 8388608<br>
><br>
<br>
Having large system buffers like that just leads to buffer bloat<br>
problems. Squid is still the bottleneck if it is sending only 4KB each<br>
I/O cycle to the client - no matter how much is already received by<br>
Squid, or stuck in kernel queues waiting to arrive to Squid. The more<br>
heavily loaded the proxy is the longer each I/O cycle gets as all<br>
clients get one slice of the cycle to do whatever processing they need done.<br>
<br>
The buffers limited by HTTP_REQBUF_SZ are not dynamic so its not just a<br>
minimum. Nathan found a 300% speed increase from a 3x buffer size<br>
increase. Which is barely noticable (but still present) on small<br>
responses, but very noticable with large transactions.<br>
<br>
Amos<br>
<br>
______________________________<wbr>_________________<br>
squid-users mailing list<br>
<a href="mailto:squid-users@lists.squid-cache.org">squid-users@lists.squid-cache.<wbr>org</a><br>
<a href="http://lists.squid-cache.org/listinfo/squid-users" rel="noreferrer" target="_blank">http://lists.squid-cache.org/<wbr>listinfo/squid-users</a><br>
</blockquote></div></div>