Het was niet toen ik het laatst instelde.
Ik heb openspeedtest gebruikt. Ookla kon sneller testen op dezelfde VM die ik had ingericht, en was veel consistenter bij snelle verbindingen.
Dat was de beste van de gratis tools overigens.
Hmm, het opzetten van eentje achter een login op de publieke zijde is niet zo’n slecht idee. VPN-gebaseerde externe gebruikers is een groot punt hier. Veel klanten klagen dat hun speedtest x aangeeft, terwijl ze enkele staten verder van onze datacenter vandaan zijn, en proberen uit te leggen dat de speedtest gekoppeld is aan een lokale node, en dat het lagere latentie heeft, en dat het door verschillende providers gaat, enzovoort.
Twijfel.
100 Gbps is 12,5 GB/s, gemiddelde server DDR4 is ~20 GB/s, docker zou ten minste één in-memory kopie-operatie toevoegen; CDNs kunnen dat optimaliseren door zero-copy-operaties binnen de kernel te gebruiken, maar dat is niet beschikbaar voor Docker, voor zover ik weet, tenzij je spreekt over speciale Docker-kernel Optimalisaties.
Misschien zou het net met DDR5 mogelijk zijn, maar je verliest nog steeds een groot deel van de potentiele doorvoer.
Bijvoorbeeld: Netflix moest ondersteuning voor zero-copy TLS in de FreeBSD-kernel ontwikkelen om een lijnsnelheid van 100 Gbps op bare metal te bereiken met hun OpenConnect-cache.
Tenzij er nieuwere netwerktechnieken in Docker zijn sinds de laatste keer dat ik heb gekeken/tested.
Dat is wild. CDN-caching of zoiets?
Het hangt af van de client-machine; als je iets hebt dat uit 2017 of nieuwer is, is meer dan 25 Gbps mogelijk met openspeedtest.
Op mijn M1 MacMini kan ik 30 Gbps halen op Safari en 27 Gbps op Chrome.
Kun je een nieuwe poging doen? Als je dat jaren geleden hebt getest…