Etherpad-lite: Degradación del rendimiento en 1.8.0 y versiones más recientes

Cc @seballot

Tenemos cobertura de prueba para este afaik. Ver prueba de interfaz de respuesta.

El problema del reflujo es más fácil de realizar cuando hay una gran cantidad de nodos.
¿Es ése? https://github.com/ether/etherpad-lite/blob/develop/tests/frontend/specs/responsiveness.js
Esta comentado

Vaya, descomentaré y me aseguraré de que tengamos una cobertura de prueba de trabajo. Con suerte, @seballot puede encontrar una solución de rendimiento rápidamente :)

gracias @JohnMcLear!

Sin comentarios, gracias por el informe de errores realmente completo y bien elaborado. Golpeará a

Aún no hemos recibido @seballot a pesar del correo electrónico / cc aquí. Supongo que está de vacaciones y se ocupará de esto lo antes posible, pero si alguien más puede intentarlo mientras esperamos, sería ideal :)

Hola chicos ! gracias por este informe de error muy claro @joassouza , y perdón por el error

Lo siento, estoy muy concentrado en otro proyecto en este momento, intentaré echar un vistazo de cerca a este boleto la próxima semana. Pero si alguien quiere intentar resolverlo sea mi invitado !!

@seballot solo un golpe para la próxima semana para asegurarse de tener algo de tiempo en su agenda para echar un vistazo a esto, por favor :) ¡Gracias!

Hola !

No puedo reproducir, hice un pad de 6000 líneas y funciona bien

Probado en Debian 9 -> Chromium 73 y Firefox 68

¿Por qué sus números de línea se ven mal (el número 1 se muestra bien, luego el número 2 es demasiado grande y no está alineado)?
¿Podría ser un problema en su código local?
¿Quizás la degradación del rendimiento es solo en Mac? ¿Alguien más puede intentarlo por favor?

No lo he probado, pero puedo ver que la prueba de respuesta de Firefox falló que solía pasar. Pruebe la prueba de respuesta de Firefox con un conjunto sin piel para ver si pasó.

pase de prueba para mí tanto en chromium como en firefox

Sí, simplemente pasó para mí también, así que necesito profundizar, pero me pregunto si pasa por nosotros porque estamos en pc rápidos (ish) y los laboratorios de salsa arrojan una máquina virtual campesina para manejar la tarea.

También experimento retraso cero en ff en ubuntu

De acuerdo, cambiar amount a 1600000 (crea 8k líneas) hace que el retraso sea notable para mí.

Intenta hacer eso @seballot , tests/frontend/specs/responsiveness.js línea 26

Sin embargo, no puedo confirmar si se trata de un error nuevo, valdría la pena revisar 1.7.9 o lo que sea y asegurarse de que el comportamiento sea realmente diferente. Debe haber una razón por la que la prueba de capacidad de respuesta se situó alrededor de la marca de 1k líneas.

También vale la pena señalar que la experiencia en Firefox 52 es el problema, ¿el FF moderno parece estar bien? La prueba de capacidad de respuesta falla en FF 52 pero está bien en 80. De hecho, bloquea el navegador. - ¿Supongo que probarlo en Firefox 52? Estoy probando en SL ahora.

La prueba de respuesta falla en this.timeout no es un error de función. https://github.com/ether/etherpad-lite/pull/4257/files

Solo para dar más contexto. Las pruebas se realizaron en Chrome en MacOs. Podríamos reproducir el mismo error en máquinas realmente rápidas como i9, 64 GB de RAM.
@seballot, ¿ podrías intentar editar al principio del pad?
También lo probé en una máquina con Windows que usa Chrome y tengo el mismo retraso.
https://video.etherpad.com/p/example_long_pad

He estado probando Firefox como un idiota, probaré Chrome ahora.

Está bien, sí, esto es malo. Cambié la cantidad a 800000 y el retraso es horrible.

Creo que el retraso aumenta si editas al principio del pad. Como, en la primera línea.

No estoy demasiado familiarizado con las herramientas de rendimiento de Chrome, pero esto es lo que veo cuando trato de editar el panel responsiveness.js.

¿Te das cuenta de que no obtengo todo el tiempo de diseño como tú?

Probé FF en una máquina con Windows y tengo el mismo retraso. Usando esta almohadilla

https://video.etherpad.com/p/example_long_pad
Sobre el reflujo, depende de qué CSS se aplique, navegador, código js, ​​el desencadenante, .... Por eso he hecho las pruebas sin ningún complemento. Tengo que verificar el código de la prueba de capacidad de respuesta para entender por qué en esas pruebas ustedes no se dan cuenta del retraso.

Hola ! de hecho, con 8K comienza a congelarse. Pero cambié a 1.7.5 y con el pad de 8k se congela igual (¡incluso lo diría peor!)

De todos modos, es un hecho que etherpad se vuelve lento cuando los pads son demasiado grandes. No creo que sea un error crítico, porque los blocs de notas no están hechos para escribir libros, y creo que la mayoría de la gente los usa para textos cortos.

Pero sí, probablemente podríamos mejorar. Pero creo que será un trabajo doloroso :) Además, no estoy seguro de que solo se relacione con la eliminación del diseño estándar, porque una especificidad es que etherpad usa iframes diferentes, por lo que siempre necesitamos ejecutar javascript para alinear el diseño entre sí (para la altura de la línea, por ejemplo)

Intentaría echarle un vistazo, pero no prometo nada porque
1- no parece muy divertido :)
2- No siento que sea un error crítico

@JohnMcLear Traté de echar un vistazo ahora, pero no entiendo, cada cambio que hago en ace2_inner.js (incluso borrando todo el archivo) no afecta mi instancia local, sigue funcionando igual. ¿Qué me estoy perdiendo?

ace2_inner.js se solicita sin la cadena de versión atm, por lo que la URL de ace2_inner.js no cambia y se utiliza la caché de su navegador. Cuando establece maxAge = 0 en settings.json y / o deshabilita la caché del navegador, debería servir el nuevo archivo sin reiniciar.

¡Hola @ webzwo0i ! Gracias por tu ayuda ! Finalmente recuerdo que necesito invalidarme el caché de ace2_inner porque está cargado en el iframe ...

(maxAge = 0 no tuvo ningún impacto por cierto)

Un poco tarde ahora, ¡se verá mañana!

Un truco es usar la pestaña de red abierta ya que deshabilita el almacenamiento en caché.

@joassouza, ¿puedes confirmar los hallazgos de Sebastians?

OK hecho ! en realidad no fue muy complicado, gracias a @joassouza que hizo todo el trabajo de encontrar tanto el problema como la solución

y confirmo que el error no está relacionado con cambios recientes en la interfaz de usuario, ¡creo que ha estado ahí durante mucho tiempo!

Supongo que esto se puede cerrar ahora con la solución # 4267
Gracias una vez más @seballot