Etherpad-lite: 1.8.0 이상 버전에서 성능 저하

참조 @seballot

이 afaik에 대한 테스트 범위가 있습니다. 응답 성 프런트 엔드 테스트를 참조하세요.

리플 로우의 문제는 많은 양의 노드가있을 때 더 쉽게 깨닫게됩니다.
그 거예요? https://github.com/ether/etherpad-lite/blob/develop/tests/frontend/specs/responsiveness.js
댓글이 있습니다.

오, 이런, 나는 주석을 제거하고 우리가 작동하는 테스트 범위가 있는지 확인합니다. @seballot 가 성능 수정을 서둘러 찾을 수 있기를 바랍니다. :)

감사합니다 @JohnMcLear!

주석이 없습니다. 정말 철저하고 잘 정리 된 버그 보고서에 감사드립니다. @seballot를 다시 범프합니다 : +1 :

아직 @seballot 에서

안녕하세요! 이 매우 명확한 버그 보고서 @joassouza에 감사 드리며 버그에 대해 죄송합니다

지금은 다른 프로젝트에 집중해서 죄송합니다. 다음주에이 티켓을 자세히 살펴 보도록하겠습니다. 하지만 누군가 해결하고 싶다면 내 손님이 되십시오!

@seballot 는 이번 주에 일정에 시간을 할애하여 이것을 확인하십시오. :) 감사합니다!

안녕하세요 !

재현 할 수없고 6000 줄의 긴 패드를 만들었는데 잘 작동합니다.

Debian 9-> Chromium 73 및 Firefox 68에서 테스트 됨

줄 번호가 나빠 보이는 이유는 무엇입니까 (1 번은 괜찮게 표시되고 2 번부터는 너무 커서 정렬되지 않음)?
현지 규정에 문제가 있습니까?
성능 저하가 Mac에서만 발생하는 것일까 요? 다른 사람이 제발 시도 할 수 있습니까?

테스트하지는 않았지만 통과했던 Firefox 응답 테스트 실패를 볼 수 있습니다. 스킨이없는 상태에서 Firefox 반응 형 테스트를 시도하여 통과했는지 확인 하시겠습니까?

크롬과 파이어 폭스에서 나를 위해 테스트 통과

네, 나에게도 통과했습니다. 그래서 더 깊이 파고 들어야합니다.하지만 우리가 빠른 (ish) PC를 ​​사용하고 있고 소스 연구소가 작업을 처리하기 위해 농민 VM을 던지기 때문에 통과하는지 궁금합니다.

나는 또한 우분투에서 ff에서 제로 지연을 경험합니다.

좋습니다. amount 를 1600000 (8k 라인 생성)로 변경하면 지연이 눈에 띄게 나타납니다.

@seballot , tests/frontend/specs/responsiveness.js line 26 해보십시오.

이것이 새로운 버그인지 확인할 수는 없지만 1.7.9 등을 확인하고 동작이 실제로 다른지 확인하는 것이 좋습니다. 응답 성 테스트가 약 1k 라인 표시에 있었던 이유가 있어야합니다.

Firefox 52에서의 경험이 문제라는 점도 주목할 가치가 있습니다. 최신 FF는 괜찮아 보입니다. 응답 성 테스트는 FF 52에서 충돌하지만 80 에서는 괜찮습니다.

this.timeout 에서 응답 테스트가 실패하면 함수 오류가 아닙니다. https://github.com/ether/etherpad-lite/pull/4257/files

더 많은 맥락을 제공하기 위해. 테스트는 MacO의 Chrome에서 이루어졌습니다. i9, 64GB RAM과 같은 매우 빠른 시스템에서 동일한 오류를 재현 할 수 있습니다.
@seballot 패드의 시작 부분에서 편집 해 볼 수 있습니까?
방금 크롬을 사용하는 Windows 컴퓨터에서도 시도해 보았고 동일한 지연이 있습니다.
https://video.etherpad.com/p/example_long_pad

나는 바보처럼 Firefox를 테스트 해 왔으며 지금 Chrome을 테스트 할 것입니다.

그래,와, 이건 나쁘다. 금액을 800000 변경했는데 지연이 끔찍합니다.

패드의 시작 부분에서 편집하면 지연이 증가한다고 생각합니다. 그것의 첫 줄처럼.

Chrome 성능 도구에 너무 익숙하지는 않지만 responsiveness.js 패드를 편집하려고 할 때 표시됩니다.

내가 당신처럼 모든 레이아웃 시간을 얻지 못하는 것을 알 수 있습니까?

Windows 시스템에서 FF를 시도했지만 동일한 지연이 있습니다. 이 패드 사용

https://video.etherpad.com/p/example_long_pad
리플 로우는 어떤 CSS가 적용되는지, 브라우저, js 코드가 트리거하는지에 따라 달라집니다. 그래서 플러그인없이 테스트를 수행했습니다. 응답 테스트의 코드를 확인하여 왜 이러한 테스트에서 지연을 인식하지 못하는지 이해해야합니다.

안녕하세요 ! 실제로 8K에서는 얼기 시작합니다. 그러나 나는 1.7.5로 전환했고 8k의 패드로 똑같이 얼어 붙습니다 (심지어 최악이라고 말할 것입니다!)

어쨌든 패드가 너무 크면 etherpad가 느려지는 것은 사실입니다. 나는 그것이 중요한 버그라고 생각하지 않는다. 왜냐하면 패드는 책을 쓰기위한 것이 아니기 때문이다. 그리고 나는 대부분의 사람들이 그것들을 짧은 텍스트에 사용한다고 생각한다.

하지만 예, 우리는 개선 할 수 있습니다. 그러나 나는 그것이 고통스러운 일이 될 것이라고 생각합니다 :) 또한 한 가지 특이성은 etherpad가 다른 iframe을 사용하고 있기 때문에 레이아웃을 정렬하기 위해 항상 자바 스크립트를 실행해야하기 때문에 표준 레이아웃 휴지통에만 관련이 있는지 확실하지 않습니다. 서로 사이 (예 : 줄 높이)

한 번 보려고했지만 약속은 안 해
1-별로 재미 있지 않은 것 같습니다. :)
2- 중요한 버그라고 생각하지 않습니다.

@JohnMcLear 지금 살펴 보려고했지만 ace2_inner.js 대한 모든 변경 사항 (전체 파일 삭제 포함)이 내 로컬 인스턴스에 영향을주지는 않지만 여전히 동일하게 작동합니다. 내가 무엇을 놓치고 있습니까?

ace2_inner.js는 버전 문자열 atm없이 요청되므로 ace2_inner.js에 대한 URL이 변경되지 않고 브라우저 캐시가 사용됩니다. settings.json에서 maxAge = 0을 설정하거나 브라우저 캐시를 비활성화하면 다시 시작하지 않고 새 파일을 제공해야합니다.

안녕하세요 @ webzwo0i ! 도와 주셔서 감사합니다 ! 마침내 iframe에로드 되었기 때문에 ace2_inner의 캐시를 무효화해야한다는 것을 마침내 기억합니다.

(maxAge = 0은 btw에 영향을 미치지 않았습니다)

지금 조금 늦게 내일 봐요!

한 가지 트릭은 캐싱을 비활성화 할 때 네트워크 탭 열기를 사용하는 것입니다.

@joassouza Sebastians 결과를 확인할 수 있습니까?

좋아. 끝났어 ! 실제로 문제와 해결책을 찾는 모든 작업을 수행 한

그리고 버그가 최근 UI 변경과 관련이 없다는 것을 확인했습니다. 오랫동안 거기에 있었던 것 같습니다!

나는 이것이 수정 # 4267로 이제 닫힐 수 있다고 생각합니다.
한 번 더 감사합니다 @seballot