Websockify: Reconsidérer l'utilisation et la recommandation de numpy
Actuellement, websockify/websocket.py donnera un avertissement si "numpy" n'est pas disponible :
ATTENTION : pas de module 'numpy', le protocole HyBi est plus lent ou désactivé
C'est quelque peu déroutant. Tout d'abord, HyBi n'est certainement pas "désactivé". Et est-ce vraiment plus lent ? J'ai fait quelques tests avec noVNC, et même lors de la lecture de vidéos Youtube avec une fréquence d'images élevée, le processus utilisant websocket.py ne consomme pas du tout beaucoup de CPU ; il apparaît rarement dans la liste « en haut ». Je me demande donc si des mesures réelles ont été effectuées à ce sujet ? J'ai fait quelques recherches sur Google et je n'ai rien trouvé (sauf des problèmes avec numpy...). À mon humble avis, à moins que nous puissions mesurer que numpy fait une différence substantielle, je pense qu'il serait préférable et plus propre de n'exiger que la fonctionnalité Python standard.
astrand
Tous les 2 commentaires
La partie "plus lente ou désactivée" est due au fait qu'il existe 4 modules python différents qui sont facultatifs et vérifiés à l'aide du même code en haut de websocket.py. Par exemple, si le module SSL n'est pas trouvé, TLS/wss est désactivé. Je viens de pousser un changement qui rendra cela plus clair.
Numpy est définitivement plus rapide. En utilisant le test tests/latency.py + tests/latency.html, j'obtiens les résultats suivants (avec un délai d'envoi de 10 ms et fonctionnant uniquement sur localhost):
Taille du paquet 2000 octets :
- Latence aller-retour moyenne de 0,8 ms avec numpy
- Latence aller-retour moyenne de 1,6 ms sans numpy
Taille du paquet 20000 octets :
- Latence aller-retour moyenne de 2,5 ms avec numpy
- Latence aller-retour moyenne de 9,2 ms sans numpy
Taille du paquet 100000 octets :
- Latence aller-retour moyenne de 6,3 ms avec numpy
- Latence moyenne de 40,1 ms sans numpy
De plus, avec des tailles de paquets de 100 Ko, non seulement la latence est plus de 6 fois plus élevée sans numpy, mais le serveur commence à prendre du retard et le client doit reculer à plusieurs reprises pendant le test.
Notez que numpy n'affecte vraiment que le démasquage des données client->serveur, donc pour des utilisations comme noVNC, cela ne sera fondamentalement pas pertinent. Cependant, websockify n'est pas uniquement destiné à noVNC, donc dans le cas où le client envoie beaucoup de données au serveur, numpy améliore considérablement les performances.
kanaka
le 20 avr. 2013
Merci!
astrand
le 22 avr. 2013
Questions connexes
doriwal
·
26Commentaires
dwt
·
3Commentaires
gpetukhov
·
3Commentaires
maanbsat
·
3Commentaires
gw0
·
3Commentaires
Commentaire le plus utile
La partie "plus lente ou désactivée" est due au fait qu'il existe 4 modules python différents qui sont facultatifs et vérifiés à l'aide du même code en haut de websocket.py. Par exemple, si le module SSL n'est pas trouvé, TLS/wss est désactivé. Je viens de pousser un changement qui rendra cela plus clair.
Numpy est définitivement plus rapide. En utilisant le test tests/latency.py + tests/latency.html, j'obtiens les résultats suivants (avec un délai d'envoi de 10 ms et fonctionnant uniquement sur localhost):
Taille du paquet 2000 octets :
Taille du paquet 20000 octets :
Taille du paquet 100000 octets :
De plus, avec des tailles de paquets de 100 Ko, non seulement la latence est plus de 6 fois plus élevée sans numpy, mais le serveur commence à prendre du retard et le client doit reculer à plusieurs reprises pendant le test.
Notez que numpy n'affecte vraiment que le démasquage des données client->serveur, donc pour des utilisations comme noVNC, cela ne sera fondamentalement pas pertinent. Cependant, websockify n'est pas uniquement destiné à noVNC, donc dans le cas où le client envoie beaucoup de données au serveur, numpy améliore considérablement les performances.