PerfUG Mardi 5 novembre 2013: Need for Speed: Packet edition

PerfUG
Mardi 5 novembre 2013: Need for Speed: Packet edition
Raphaël Luta @raphaelluta
Présentation pour les développeurs sur les impacts du réseau sur les applicatifs

Différence de point de vue fondamentale entre un développeur d’application et un administrateur réseau.

Caractéristiques d’un réseau et analogie avec une route:
- bande passante: largeur totale
- latence: limitation de vitesse
- taux d’erreur: crash
- duplex: double voie
- MTU: largeur d’une voie
- jitter (variabilité de la latence): rétrécissement de la voie

Conditions idéales: full duplex, taux d’erreur très faible (mais non nul, cf les fenêtres plus bas), MTU aussi gros que possible (1500 octets sur Internet)

Le problème le plus génant n’est pas la bande passante mais la latence, en principe toutes les optimizations ont pour but in fine d’améliorer la latence. En 20 ans sur internet la bande passante s’est améliorée 1000 fois plus que la latence.

Vitesse théorique dans une fibre: 5ms par 1000km. Paris - San Francisco = 9000km = 45ms minimum.

Outils standards:
- ping: teste connection, donne le MTU et la taille de paquet maximale (-s sur linux)
- traceroute: liste les points de passage et le temps à chaque étape, permet de visualiser comme la latence s’accumule, on peut envoyer un paquet TCP sur le port 80 (-T -p 80 sous minux) pour valider des ouvertures de flux
- tc: permet de simuler des comportements réseaux sous linux. On peut ajouter des latences, de la perte de paquets, limiter la bande passante. Très utile pour des tirs de perfs ou simuler des connections mobiles

Outils GUI:
- smokeping: appication web qui graphe des pings, très utilisé par les hébergeurs
- Network Link Conditioner: équivalent de tc pour Mac, avec des profils prédéfinis, fait partie de XCode
- TMNetSim: pareil pour windown
- Charles Proxy: proxy http qui permet d’introduire des délais

Protocoles d’échanges:
- UDP: rapide mais aucune garantie, utilisé par de la communication bas niveau (DNS, DHCP), du streaming et du monitoring (syslog)
- TCP: protocole à état qui a un surcout mais qui garantit la réception ordonnée, fournit des controles de flux

Démonstration d’une échange TCP typique

Les fenêtres:
- fenêtre du récepteur (rwnd) donné dans les paquets de confirmation pour éviter la surcharge du récepteur, taille de donnée que le récepteur peut accepter
- fenètre de congestion (cwnd) nombre de paquet donné par l’éméteur pour éviter la surcharge réseau, faible au début puis va croitre, diminue en principe quand il y a des pertes de paquets, d’où que des paquets perdus ne sont pas un problème en soit car ils permettent de détecter une surcharge.

Nombre de paquets en transit: minimum des deux.

Démonstration de la variation de la vitesse sur différents types de réseaux, impact très important de la taille des paquets sur le taux de transfert mais risque de collision.

Outils 2:
- iperf: permet d’estimer le débit entre un client et un serveur avec différents paramètres
- ss: information sur les sockets
- tcpdump: outil de capture des paquets, wireshark pour la visualization

Tuning:
- fenetre de congestion initialie initcwnd à passer à 10, gain de 20% de perf (par défaut dans les kernels > 2.6.39)
- eviter les slow start après une pause de transfert Slow-Start Restart After Idle, utile dans un avec une base de donnée avec un pool de connection ou dans un LAN
- augmenter le MTU sur une interface réseau ou une route précise

Soucis à éviter:
- encapsulation: (VPN ipsec type Cisco) qui augmente la taille de l’en-tête et donc diminue la charge utile de chaque paquet, de 25 à 30% de bande passante perdue (beaucoup plus pour de la voix sur IP)
- data bloat: quand le contenu n’est pas optimisé, SOAP par exemple
- paquets trop petits: résultats de requêtes SQL avec lazy-join en N+1, où on paye la latence sur chaque paquet

Solutions:
- éliminer le bruit (metadonnées inutiles)
- contenus plus denses (noms moins longs, répétitions de valeurs)
- protocoles plus efficaces Protobuf, Thrift, Avro, au pire JSON
- réutilisation de connection, 100Ko pour que la vitesse soit bien établie, spécialement sur SSL qui ajoute 2 round trip au minimum
- compresser les données, coût CPU de compression désormais assez faible, au pire peut se faire sur un proxy type HAProxy
- caching quand on peut

Conclusion: Fallacies of Distributed Computing -  L. Peter Deutsch
- The network is reliable
- Latency is zero
- Bandwidth is infinite
- The network is secure
- Topology doesn't change
- There is one administrator
- Transport cost is zero
- The network is homogeneous

Questions: 
- impact de la virtualization ? ça dépend des hyperviseurs et des cartes
- tuning pour les websockets pour en ouvrir plus ? augmenter la mémoire disponibles pour tcp et diminuer la taille alouée à chaque socket