Websockify: Überdenken Sie die numpy Verwendung und Empfehlung
Derzeit gibt websockify/websocket.py eine Warnung aus, wenn "numpy" nicht verfügbar ist:
WARNUNG: kein 'numpy'-Modul, HyBi-Protokoll ist langsamer oder deaktiviert
Das ist etwas verwirrend. Zunächst einmal ist HyBi definitiv nicht "deaktiviert". Und ist es wirklich langsamer? Ich habe einige Tests mit noVNC durchgeführt, und selbst beim Abspielen von Youtube-Videos mit einer hohen Bildrate verbraucht der Prozess mit websocket.py nicht viel CPU; es taucht nur selten in der "Top"-Liste auf. Ich frage mich also, ob dazu echte Messungen durchgeführt wurden? Ich habe etwas gegoogelt und nichts gefunden (außer Probleme mit numpy...). IMHO, es sei denn, wir können messen, dass numpy einen wesentlichen Unterschied macht, denke ich, dass es besser und sauberer wäre, nur die Standard-Python-Funktionalität zu erfordern.
astrand
Alle 2 Kommentare
Der "langsamere oder deaktivierte" Teil liegt daran, dass es 4 verschiedene Python-Module gibt, die optional sind und mit demselben Code oben auf websocket.py überprüft werden. Wenn beispielsweise das SSL-Modul nicht gefunden wird, wird TLS/wss deaktiviert. Ich habe gerade eine Änderung vorangetrieben, die dies klarer macht.
Numpy ist definitiv schneller. Mit dem Test tests/latency.py + tests/latency.html erhalte ich die folgenden Ergebnisse (mit 10 ms Sendeverzögerung und nur auf localhost ausgeführt):
Paketgröße 2000 Byte:
- 0,8 ms durchschnittliche Roundtrip-Latenz mit numpy
- 1,6 ms durchschnittliche Roundtrip-Latenz ohne numpy
Paketgröße 20000 Byte:
- 2,5 ms durchschnittliche Roundtrip-Latenz mit numpy
- 9,2 ms durchschnittliche Roundtrip-Latenz ohne numpy
Paketgröße 100000 Byte:
- 6,3 ms durchschnittliche Roundtrip-Latenz mit numpy
- 40,1 ms durchschn. Roundtrip-Latenz ohne numpy
Darüber hinaus ist bei 100kb Paketgröße nicht nur die Latenz 6 mal höher ohne numpy, sondern der Server gerät ins Hintertreffen und der Client muss sich während des Tests immer wieder zurückziehen.
Beachten Sie, dass numpy wirklich nur die Demaskierung von Client-> Server-Daten betrifft, sodass es für Anwendungen wie noVNC im Grunde irrelevant ist. Websockify ist jedoch nicht nur für noVNC gedacht. Wenn der Client also viele Daten an den Server sendet, bietet numpy eine erhebliche Leistungsverbesserung.
kanaka
am 20. Apr. 2013
Vielen Dank!
astrand
am 22. Apr. 2013
Verwandte Themen
doriwal
·
26Kommentare
mitsuhiko
·
3Kommentare
DarwinSurvivor
·
3Kommentare
jacquev6
·
3Kommentare
maanbsat
·
3Kommentare
Hilfreichster Kommentar
Der "langsamere oder deaktivierte" Teil liegt daran, dass es 4 verschiedene Python-Module gibt, die optional sind und mit demselben Code oben auf websocket.py überprüft werden. Wenn beispielsweise das SSL-Modul nicht gefunden wird, wird TLS/wss deaktiviert. Ich habe gerade eine Änderung vorangetrieben, die dies klarer macht.
Numpy ist definitiv schneller. Mit dem Test tests/latency.py + tests/latency.html erhalte ich die folgenden Ergebnisse (mit 10 ms Sendeverzögerung und nur auf localhost ausgeführt):
Paketgröße 2000 Byte:
Paketgröße 20000 Byte:
Paketgröße 100000 Byte:
Darüber hinaus ist bei 100kb Paketgröße nicht nur die Latenz 6 mal höher ohne numpy, sondern der Server gerät ins Hintertreffen und der Client muss sich während des Tests immer wieder zurückziehen.
Beachten Sie, dass numpy wirklich nur die Demaskierung von Client-> Server-Daten betrifft, sodass es für Anwendungen wie noVNC im Grunde irrelevant ist. Websockify ist jedoch nicht nur für noVNC gedacht. Wenn der Client also viele Daten an den Server sendet, bietet numpy eine erhebliche Leistungsverbesserung.