atomt

11 ms·

1.
by atomt 2y ago
I've seen concurrency in excess of 500 from Metas crawlers to a single site. That site had just moved all their images so all the requests hit the "pretty url" rewrite into a slow dynamic request handler. It did not go very w
2.
by atomt 3y ago
I was hoping they would extend it for a bit longer, not because I want to be running old versions but because 3.0/3.1 have some massive performance regressions that are yet to be fixed. Have a look at HAProxys latest release announceme
3.
by atomt 4y ago
Direct hit to the heart *cries in BGP and big enterprise switches*
4.
by atomt 5y ago
Norway. Most of the FTTH plans seems to be symmetrical, anything from 100Mbps to 1Gbps. Some GPON based networks will hold back upstream at 500Mbps max (but they are fairly rare. Most is active ethernet anyway, not GPON) FTTH is quickly tak
5.
by atomt 7y ago
If nginx decided to support ktls they could use sendfile for encrypted traffic as well. Unsure if it is worth it just to make sendfile work however.
6.
by atomt 7y ago
I have no idea about the economics in this area, but it kind of baffles me that they add these propietary, closed source and buggy "accelerators" instead of improving the cores a bit. A bit more L1 cache would go a long way for ne
7.
by atomt 7y ago
The problem I have with THP is that while it initially looks great on our workload (yay! a core saved per server!), it often starts to degrade badly after several days or even many weeks depending on memory fragmentation and pressure. It ke
8.
by atomt 9y ago
It was declared ready for "experimentation" about a year ago or so, so not very mature. If you are on current upstream versions it is not too bad, I'm using it here and there on not very important things. It is a bit hit and
9.
by atomt 9y ago
That example is made needlessly complicated to compress down to a one-liner and show off maps. It does look nicer when properly formatted as part of a rule file, however. The docs needs some work.
10.
by atomt 9y ago
That is good to know. I just deployed BBR on some pilot virtio backed VMs yesterday and I missed this. As far as I can tell the Actual Hardware I'm running my other BBR pilots on are doing the right thing. File under: BBR - still a got
11.
by atomt 9y ago
Just loading the sysctl values will not switch the packet scheduler on already existing network interfaces, but it will start using BBR on new sockets. Switching the scheduler at runtime using tc qdisc replace is possible, but then you need
12.
by atomt 9y ago
To try it out, make sure that your Linux kernel has: CONFIG_TCP_CONG_BBR CONFIG_NET_SCH_FQ (not to be confused with FQ_CODEL) Put these into /etc/sysctl.conf: net.core.default_qdisc=fq net.ipv4.tcp_congestion_control=bbr Reboot.
13.
by atomt 9y ago
A warning if you want to try out BBR yourself: Due to how BBR relies on pacing in the network stack make sure you do not combine BBR with any other qdisc ("packet scheduler") than FQ. You will get very bad performance, lots of ret
14.
by atomt 9y ago
Another way to trigger a bounce would be to have the evil domain purposefully having strict SPF and DMARC policy set.
15.
by atomt 9y ago
For Intel processors, on Linux, the "turbostat" utility provides much of the same information using the -d switch.
16.
by atomt 12y ago
And AT&T with their huge 6rd deployment for DSL.
17.
by atomt 12y ago
That is their usual excuse. But its just a bogus answer to shut people up - its not only THEIR customers you want to communicate with.
18.
by atomt 12y ago
At work (a larger enterprise in Europe) we already see quite a bit of pain with IPv4. B2B connections are increasingly not using globally unique addressing anymore, so we often need to use prefix NAT and application level proxies to bridge