Websockify: Reconsiderar o uso e recomendação numpy
Atualmente, websockify / websocket.py dará um aviso se "numpy" não estiver disponível:
AVISO: nenhum módulo 'numpy', o protocolo HyBi é mais lento ou desabilitado
Isso é um tanto confuso. Em primeiro lugar, HyBi definitivamente não está "desativado". E é realmente mais lento? Fiz alguns testes com noVNC, e mesmo ao reproduzir vídeos do Youtube com uma alta taxa de quadros, o processo usando websocket.py não consome muito CPU; raramente aparece na lista "principal". Então, estou me perguntando, alguma medida real foi feita sobre isso? Eu fiz algumas pesquisas no Google e não consegui encontrar nada (exceto problemas com numpy ...). IMHO, a menos que possamos medir que numpy faz uma diferença substancial, acho que seria melhor e mais limpo exigir apenas a funcionalidade padrão do Python.
astrand
Todos 2 comentários
A parte "mais lenta ou desabilitada" é porque existem 4 módulos Python diferentes que são opcionais e verificados usando o mesmo código no topo do websocket.py. Por exemplo, se o módulo ssl não for encontrado, o TLS / wss será desativado. Acabei de empurrar uma mudança que tornará isso mais claro.
O Numpy é definitivamente mais rápido. Usando o teste tests / latency.py + tests / latency.html, eu obtenho os seguintes resultados (com 10 ms de atraso no envio e apenas executando no localhost):
Tamanho do pacote de 2.000 bytes:
- Latência média de ida e volta de 0,8 ms com numpy
- Latência média de ida e volta de 1,6 ms sem entorpecimento
Tamanho do pacote 20.000 bytes:
- Latência média de 2,5 ms de ida e volta com numpy
- Latência média de ida e volta de 9,2 ms sem entorpecimento
Tamanho do pacote de 100.000 bytes:
- Latência média de ida e volta de 6,3 ms com numpy
- 40,1 ms média de latência de rountrip sem entorpecimento
Além disso, com tamanhos de pacote de 100kb, não apenas a latência é 6 vezes maior sem entorpecente, mas o servidor começa a ficar para trás e o cliente tem que recuar repetidamente durante o teste.
Note que numpy realmente afeta apenas o desmascaramento de dados cliente-> servidor, então para usos como noVNC será basicamente irrelevante. No entanto, websockify não é apenas para noVNC, portanto, no caso em que o cliente está enviando muitos dados para o servidor, o numpy fornece uma melhoria significativa de desempenho.
kanaka
em 20 abr. 2013
Obrigado!
astrand
em 22 abr. 2013
Questões relacionadas
doriwal
·
26Comentários
zmsmith
·
5Comentários
kmike
·
16Comentários
lukaszb
·
14Comentários
jodal
·
15Comentários
Comentários muito úteis
A parte "mais lenta ou desabilitada" é porque existem 4 módulos Python diferentes que são opcionais e verificados usando o mesmo código no topo do websocket.py. Por exemplo, se o módulo ssl não for encontrado, o TLS / wss será desativado. Acabei de empurrar uma mudança que tornará isso mais claro.
O Numpy é definitivamente mais rápido. Usando o teste tests / latency.py + tests / latency.html, eu obtenho os seguintes resultados (com 10 ms de atraso no envio e apenas executando no localhost):
Tamanho do pacote de 2.000 bytes:
Tamanho do pacote 20.000 bytes:
Tamanho do pacote de 100.000 bytes:
Além disso, com tamanhos de pacote de 100kb, não apenas a latência é 6 vezes maior sem entorpecente, mas o servidor começa a ficar para trás e o cliente tem que recuar repetidamente durante o teste.
Note que numpy realmente afeta apenas o desmascaramento de dados cliente-> servidor, então para usos como noVNC será basicamente irrelevante. No entanto, websockify não é apenas para noVNC, portanto, no caso em que o cliente está enviando muitos dados para o servidor, o numpy fornece uma melhoria significativa de desempenho.