Etherpad-lite: Degradação de desempenho em 1.8.0 e versões mais recentes

Cc @seballot

Temos cobertura de teste para este afaik. Veja teste de front-end de capacidade de resposta.

O problema do refluxo é mais fácil de perceber quando há uma grande quantidade de nós.
É esse? https://github.com/ether/etherpad-lite/blob/develop/tests/frontend/specs/responsiveness.js
Está comentado

Oh cara, vou descomentar e garantir que temos cobertura de teste de trabalho. Esperançosamente @seballot pode encontrar uma solução de desempenho rapidamente :)

obrigado @JohnMcLear!

Sem comentários, obrigado pelo relatório de bug realmente completo e bem elaborado. Bump @seballot novamente: +1:

Ainda não recebi resposta de

Oi pessoal ! obrigado por este relatório de bug muito claro @joassouza , e desculpe pelo bug

Desculpe, estou muito focado em outro projeto agora, vou tentar dar uma olhada neste ticket na próxima semana. Mas se alguém quiser tentar resolver fique à vontade !!

@seballot é só um

Oi !

Não consigo reproduzir, fiz um bloco de 6.000 linhas e funciona bem

Testado em Debian 9 -> Chromium 73 e Firefox 68

Por que seus números de linha parecem ruins (o número 1 é exibido corretamente, então do número 2 é muito grande e não está alinhado)?
Pode ser um problema no seu código local?
Talvez a degradação do desempenho seja apenas no Mac? outra pessoa pode tentar, por favor?

Não testei, mas posso ver a falha do teste responsivo do Firefox que costumava passar. Experimente o teste responsivo do Firefox sem skin definido para ver se passou?

teste aprovado para mim em cromo e firefox

Sim, também passou para mim, então eu preciso cavar mais fundo, mas eu me pergunto se isso passa para nós porque estamos em um computador rápido (ish) e os laboratórios de molho oferecem alguns vm camponeses para lidar com a tarefa?

Eu também experimento zero lag no ff no ubuntu

Ok, então mudar amount para 1600000 (cria 8k linhas) torna o lag perceptível para mim.

Tente fazer isso @seballot , tests/frontend/specs/responsiveness.js line 26

Não posso confirmar se este é um bug novo, porém, valeria a pena verificar 1.7.9 ou qualquer outro e garantir que o comportamento é realmente diferente. Deve haver um motivo pelo qual o teste de capacidade de resposta estava em torno da marca de 1k linhas.

Também vale a pena notar que a experiência no Firefox 52 é o problema, o FF moderno parece bom? O teste de capacidade de resposta trava no FF 52, mas funciona no 80. Na verdade, trava o navegador. - Então eu acho que testar no Firefox 52? Estou testando no SL agora.

O teste responsivo falha em this.timeout não é um erro de função. https://github.com/ether/etherpad-lite/pull/4257/files

Apenas para dar mais contexto. Os testes foram feitos no Chrome em MacOs. Pudemos reproduzir o mesmo erro em máquinas muito rápidas como i9 de 64 GB de RAM.
@seballot você poderia tentar editar no início do pad?
Eu também tentei em uma máquina Windows usando o Chrome e tive o mesmo atraso.
https://video.etherpad.com/p/example_long_pad

Tenho testado o Firefox como um idiota, vou testar o Chrome agora.

Ok, uau, isso é ruim. Mudei o valor para 800000 e o atraso é horrível.

Acredito que o atraso aumenta se você editar no início do pad. Tipo, na primeira linha dele.

Não estou muito familiarizado com as ferramentas de desempenho do Chrome, mas isso é o que vejo quando tento editar o pad responsiveness.js.

Percebe que não recebo todo o tempo de layout como você?

Eu tentei no FF em uma máquina Windows e tenho o mesmo atraso. Usando este pad

https://video.etherpad.com/p/example_long_pad
Quanto ao refluxo, depende de qual CSS é aplicado, navegador, código js que o aciona, .... Por isso fiz os testes sem nenhum plugin. Tenho que verificar o código do teste de responsividade para entender porque nesses testes vocês não percebem a demora.

Oi ! na verdade, com 8K ele começa a congelar. Mas mudei para 1.7.5 e com o pad de 8k ele congelou mesmo (eu diria até pior!)

De qualquer forma, é um fato que o etherpad fica lento quando os pads são muito grandes. Não acho que seja um bug crítico, porque o pad não foi feito para escrever livros e acho que a maioria das pessoas os usa para textos curtos.

Mas sim, provavelmente podemos melhorar. Mas acho que será um trabalho doloroso :) Além disso, não tenho certeza se será relacionado apenas ao lixo do layout padrão, porque uma especificidade é que o etherpad está usando iframes diferentes e, portanto, sempre precisamos executar javascript para alinhar o layout entre si (para a altura da linha, por exemplo)

Eu tentaria dar uma olhada, mas não estou prometendo nada porque
1- não parece muito engraçado :)
2- Não acho que seja um bug crítico

@JohnMcLear Tentei dar uma olhada agora, mas não entendi, cada alteração que faço em ace2_inner.js (mesmo excluindo o arquivo inteiro) não afeta minha instância local, ela ainda funciona da mesma forma. o que estou perdendo?

ace2_inner.js é solicitado sem a string de versão atm, portanto, a URL para ace2_inner.js não muda e o cache do navegador é usado. Quando você define maxAge = 0 em settings.json e / ou desativa o cache do navegador, ele deve servir o novo arquivo sem reiniciar.

Olá @ webzwo0i ! obrigado pela ajuda! Finalmente lembro que preciso invalidar o cache do ace2_inner porque está carregado no iframe ...

(maxAge = 0 não teve impacto btw)

Um pouco tarde agora, vai olhar amanhã!

Um truque é usar a guia de rede aberta, pois ela desativa o cache.

@joassouza você pode confirmar as descobertas de Sebastian?

Feito ! na verdade não foi muito complicado, graças a @joassouza que fez todo o trabalho para encontrar o problema e a solução

e eu confirmo que o bug não está relacionado a mudanças recentes na interface do usuário, acho que já existe há muito tempo!

Acho que isso pode ser fechado agora com a correção # 4267
Obrigado mais uma vez @seballot