Websockify: Reconsidere el uso y la recomendación de numpy
Actualmente, websockify / websocket.py dará una advertencia si "numpy" no está disponible:
ADVERTENCIA: no hay módulo 'numpy', el protocolo HyBi es más lento o está desactivado
Esto es algo confuso. En primer lugar, HyBi definitivamente no está "discapacitado". ¿Y es realmente más lento? He hecho algunas pruebas con noVNC, e incluso cuando reproduzco videos de Youtube con una alta velocidad de fotogramas, el proceso que usa websocket.py no consume mucha CPU en absoluto; rara vez aparece en la lista "superior". Entonces me pregunto, ¿se han realizado mediciones reales sobre esto? Busqué en Google y no pude encontrar nada (excepto problemas con numpy ...). En mi humilde opinión, a menos que podamos medir que numpy hace una diferencia sustancial, creo que sería mejor y más limpio requerir solo la funcionalidad estándar de Python.
astrand
Todos 2 comentarios
La parte "más lenta o desactivada" se debe a que hay 4 módulos de Python diferentes que son opcionales y se verifican usando el mismo código en la parte superior de websocket.py. Por ejemplo, si no se encuentra el módulo ssl, TLS / wss está deshabilitado. Solo presioné un cambio que aclarará esto.
Numpy es definitivamente más rápido. Usando la prueba tests / latency.py + tests / latency.html obtengo los siguientes resultados (con un retraso de envío de 10ms y simplemente ejecutándose en localhost):
Tamaño del paquete 2000 bytes:
- Latencia media de ida y vuelta de 0,8 ms con numpy
- Latencia media de ida y vuelta de 1,6 ms sin numpy
Tamaño del paquete 20000 bytes:
- Latencia media de ida y vuelta de 2,5 ms con numpy
- Latencia media de ida y vuelta de 9,2 ms sin numpy
Tamaño del paquete 100000 bytes:
- 6,3 ms de latencia media de ida y vuelta con numpy
- 40,1 ms de latencia media de ida y vuelta sin numpy
Además, con tamaños de paquete de 100 kb, no solo la latencia es 6 veces mayor sin numpy, sino que el servidor comienza a retrasarse y el cliente tiene que retroceder repetidamente durante la prueba.
Tenga en cuenta que numpy realmente solo afecta al desenmascaramiento de datos cliente-> servidor, por lo que para usos como noVNC será básicamente irrelevante. Sin embargo, websockify no es solo para noVNC, por lo que en el caso de que el cliente envíe una gran cantidad de datos al servidor, numpy proporciona una mejora significativa del rendimiento.
kanaka
en 20 abr. 2013
¡Gracias!
astrand
en 22 abr. 2013
Temas relacionados
doriwal
·
26Comentarios
bartTC
·
20Comentarios
vbabiy
·
14Comentarios
loxs
·
7Comentarios
ogrisel
·
31Comentarios
Comentario más útil
La parte "más lenta o desactivada" se debe a que hay 4 módulos de Python diferentes que son opcionales y se verifican usando el mismo código en la parte superior de websocket.py. Por ejemplo, si no se encuentra el módulo ssl, TLS / wss está deshabilitado. Solo presioné un cambio que aclarará esto.
Numpy es definitivamente más rápido. Usando la prueba tests / latency.py + tests / latency.html obtengo los siguientes resultados (con un retraso de envío de 10ms y simplemente ejecutándose en localhost):
Tamaño del paquete 2000 bytes:
Tamaño del paquete 20000 bytes:
Tamaño del paquete 100000 bytes:
Además, con tamaños de paquete de 100 kb, no solo la latencia es 6 veces mayor sin numpy, sino que el servidor comienza a retrasarse y el cliente tiene que retroceder repetidamente durante la prueba.
Tenga en cuenta que numpy realmente solo afecta al desenmascaramiento de datos cliente-> servidor, por lo que para usos como noVNC será básicamente irrelevante. Sin embargo, websockify no es solo para noVNC, por lo que en el caso de que el cliente envíe una gran cantidad de datos al servidor, numpy proporciona una mejora significativa del rendimiento.