Etherpad-lite: Притормози с большим количеством разных вкладов (~ @ 700 строк)

Я не вижу этого в Firefox Nightly 23.0a1 (2013-04-27) или 19.0.2, но я вижу это в Google Chrome версии 26.0.1410.65, используя http://etherpad-lite.paas.allizom.org/p/kqOi9HF97Z (который сейчас находится в ветке разработки c8e2278afcb4f75d52af6e55ebe1e979461c63fc) на Mac OS X 10.7.5 (Intel Core i5 2,53 ГГц). Я не могу заставить Firefox работать с ЦП более чем на 50%, но я могу легко заставить процесс Google Chrome Renderer достичь 100% (просто случайная прокрутка и ввод в обоих случаях)

Кажется, его можно использовать в Firefox на этом компьютере, но я согласен, что в Chrome он слишком медленный, чтобы его можно было использовать.

Я быстро просмотрел Chrome Profiler (сейчас нет времени копаться в нем дальше), и длинный столб выглядит как минифицированный источник, я думаю, что это jquery - он тратит больше всего времени в t.event.dispatch -> s. ручка

Есть ли быстрый способ запустить etherpad-lite локально против unminified jquery, чтобы я мог видеть реальный стек (не уверен, что мне нужно сделать, чтобы исходные карты работали для этого прямо сейчас, я тоже изучу это)?

Да ладно, я вижу это в settings.json, запустит его локально с отключенной минификацией и посмотрю, не появится ли что-нибудь более полезное.

Итак, elemData.handle (ниже) занимает 32,83% процессорного времени на моем ноутбуке:

setSelection
  updateBrowserSelectionFromRep
    inCallStack
      inCallStackIfNecessary
        handleKeyEvent
          jQuery.event.dispatch
            elemData.handle

Далее идет scrollNodeVerticallyIntoView с 18,38%, затем addRange с 6,58%. Все, что ниже этого, незначительно (менее 2%)

Подтверждено также медленное на http://beta.etherpad.org/p/cA9CbQlmTY

Проблема существует в 1.2.0 из моих тестов, поэтому выполнение деления пополам, вероятно, не поможет;

Теперь существует тестовая спецификация для этой ошибки. https://github.com/ether/etherpad-lite/pull/1764

Эта ошибка существовала в исходной версии Etherpad.

Комментирование https://github.com/ether/etherpad-lite/blob/develop/src/static/js/ace2_inner.js#L4501, похоже, улучшает производительность до такой степени, что тест проходит в Chrome и не кажется есть какие-либо изначально заметные негативные побочные эффекты, но я не могу не думать, что с этим исправлением что-то не так, просто не знаю, почему мы сначала удалим все диапазоны.

Документы для removeAllRanges ... https://developer.mozilla.org/en-US/docs/DOM/Selection/removeAllRanges

Кажется, что FF отлично справляется с большими пэдами, Chrome и IE борются. IE не хватает памяти для теста, и его почти невозможно использовать на большом планшете.

Я думаю, это потребует серьезного расследования, чтобы увидеть, сможем ли мы обойти то, что блокирует. Я в значительной степени исчерпал свое время / ресурсы, чтобы потратить на это сейчас.

Поэтому я обратился к Документам Google в поисках предлагаемого решения этой проблемы, и оказалось, что способность Документов Google обрабатывать длинные документы в среде совместной работы еще хуже. Пользователи часто отключаются, а большие вставки часто отключают пользователей; Я постараюсь написать более стабильный тест, но я бы посоветовал на самом деле решить эту проблему, возможно, потребуется некоторая сексуальная магия.

Это вполне может быть проблемой, которую я видел для более чем 25 тысяч правок, поскольку это в основном длинные файлы. Во всех случаях эти планшеты тоже были длиной от 700 до 1000 строк.

Так что я бы назвал это - https://github.com/ether/etherpad-lite/issues/1380 ошибкой с ошибкой.

Я видел меньшие панели, вынуждающие отключиться от одного клиента при попытке очистить цвета авторства во всем документе, будет ли это связано или будет другой проблемой?

@iuriguilherme, вероятно, совершенно не связан

Эта ошибка может быть связана с: https://bugs.webkit.org/show_bug.cgi?id=92594

Из-за этой ошибки создается впечатление, что способ, которым в настоящее время реализован редактор, может приводить к созданию макета страницы для каждого нажатия клавиши в браузерах webkit.

Помогает ли запрос на вытягивание № 1833 в решении этой проблемы?

@dirkcuys , это помогает, но не решает эту проблему. Это снижает скорость, с которой быстрые последовательные нажатия клавиш снижают отзывчивость. В общем случае это увеличивает скорость реакции на порядок. Еще заметок в PR.

@dlongley, спасибо. Я попытался применить изменения в запросе на перенос на сервере, работающем по адресу http://pad.p2pu.org/ , но я по-прежнему получаю почти непригодную для использования производительность при использовании Chromium 28.0.1500.71 в Ubuntu 12.04.

Какие-либо предложения? Я подумываю о переходе на версию 1.1.5? Это целесообразно / возможно?

afaik проблема существует в etherpad с 0 дня.

@dirkcuys , раннюю версию вряд ли поможет. Если у вас достаточно контента в ваших блокнотах, это будет медленно, и точка. PR помогает немного смягчить проблему (скорость снижения производительности ниже), но это не настоящее решение. Проблема может быть решена только одним из двух способов: исправление для webkit, чтобы он не создавал макет страницы так часто, или изменение дизайна etherpad, чтобы он не использовал отдельный элемент DOM для каждого символа в площадку. На самом деле, оба эти исправления должны произойти в какой-то момент. Комбинация повторения макета страницы при каждом нажатии клавиши и наличие тонны элементов, которые необходимо разместить, - убийца.

В webkit была внесена ошибка, чтобы изменить его поведение, чтобы он делал больше ленивых / консолидированных обновлений, просто неясно, сможет ли кто-нибудь заняться этим в ближайшее время. Здесь, с etherpad lite, мы могли бы применить аналогичный ленивый подход, только разделив контент на отдельные элементы DOM, когда несколько человек редактировали одну и ту же область планшета. В этом случае мы можем увидеть реальный прирост производительности для большинства больших пэдов, но это более сложная конструкция, чтобы добиться правильного результата.

Есть ли отдельный элемент DOM для каждого символа? глядя на панель инструментов разработчика Chrome, похоже, что для каждой строки есть только div, а затем диапазон для вклада каждого автора в каждой строке. Единственный способ, которым я мог сократить количество элементов DOM, - это объединить строки с одним и тем же автором (или вырезанные строки без автора) в один и тот же div. Проблема будет по-прежнему сохраняться с документами с высокой степенью совместной работы, пока не будут убраны цвета автора.

Возможно, поэтому я не могу воспроизвести проблему самостоятельно. Я использую ubuntu и Chromium Version 28.0.1500.71 Ubuntu 13.04 (28.0.1500.71-0ubuntu1.13.04.1) и вставляю весь текст Hamlet (всего 4741 строку) в блокнот с PR и, пока задержка была заметно после этой пасты, он все еще был очень пригоден к употреблению.

Конечно, я был единственным в блокноте, и весь вставленный текст был от меня, поэтому имеет смысл, что производительность будет намного хуже в больших документах с большим количеством авторов в строке (поскольку было бы намного больше цветов автора. пролеты в DOM). Может ли более быстрое решение проблемы мягкое ограничение количества различных авторских цветовых диапазонов в блокноте? Может быть какая-то периодическая фоновая задача, которая может удалить самые старые диапазоны цветов автора, пока мы не достигнем предела.

Есть ли отдельный элемент DOM для каждого символа? глядя на панель инструментов разработчика Chrome, похоже, что для каждой строки есть только div, а затем диапазон для вклада каждого автора в каждой строке.

Да, извините, это построчно. Чтобы дать обзор моего понимания того, что происходит (в браузерах webkit):

1. Пользователь нажимает клавишу во время набора текста.
2. Etherpad-lite (ace) добавляет букву к существующему диапазону.
3. Etherpad-lite обновляет выбор окна, что заставляет webkit разметить страницу.
4. Etherpad-lite рассчитывает изменения.
5. Etherpad-lite генерирует и вставляет новую строку DOM (атрибуты div + span + etherpad-lite), которая включает только что набранную букву, а затем удаляет старую (вызывая больше макетов).

Если у вас тысячи строк на странице, то каждый раз, когда вы нажимаете клавишу при вводе вышеуказанного, происходит очень медленно_. Откладывание макетов страниц в webkit или выполнение некоторой комбинации DOM или более ленивое обновление на стороне etherpad-lite должно решить эту проблему.

Единственный способ, которым я мог сократить количество элементов DOM, - это объединить строки с одним и тем же автором (или вырезанные строки без автора) в один и тот же div. Проблема будет по-прежнему сохраняться с документами с высокой степенью совместной работы, пока не будут убраны цвета автора.

Комбинирование элементов DOM могло бы помочь, так же как и задержка обновлений и изменение того, как происходят обновления, например: сокращение ненужных вставок / удалений.

Возможно, поэтому я не могу воспроизвести проблему самостоятельно. Я использую ubuntu и Chromium Version 28.0.1500.71 Ubuntu 13.04 (28.0.1500.71-0ubuntu1.13.04.1) и вставляю весь текст Hamlet (всего 4741 строку) в блокнот с PR и, пока задержка была заметно после этой пасты, он все еще был очень пригоден к употреблению.

Возможно, и в этом PR немного помог. Но да, наличие блокнота, который редактировал только один человек, не приведет к замедлению так быстро, как при большом количестве изменений, внесенных разными людьми. Замедление увеличивается с увеличением количества элементов DOM, которые необходимо разместить.

Может ли более быстрое решение проблемы мягкое ограничение количества различных авторских цветовых диапазонов в блокноте? Может быть какая-то периодическая фоновая задача, которая может удалить самые старые диапазоны цветов автора, пока мы не достигнем предела.

Да, это помогло бы немного смягчить проблему. Однако я не уверен, что это решение, которое хотелось бы людям, которые сталкиваются с этой проблемой. Даже в этом случае, если панель достаточно велика, единственный редактор замедляет работу больше, чем следует считать приемлемым (или «хорошей производительностью»).

Прошло несколько месяцев с момента описанного выше (очень признательного) отладочного спринта: если я правильно понимаю, проблема была проанализирована и идентифицирована, верно?
Какая помощь нужна, чтобы сделать этот шаг? Теперь, когда была выпущена версия 1.3 и, как мы надеемся, проблемы с коррупцией решены, это (снова) основной блокировщик для широкого использования etherpad lite на Викимедиа.

Проблема, похоже, в том, что у браузера много дел. Мы, вероятно, могли бы оптимизировать несколько частей здесь и там, но, если мы не найдем совершенно другой процесс редактирования, проблема по-прежнему в том, что есть много вещей, которые нужно сделать.

Что вы делаете, если хотите быстро выполнить множество задач? Вы запускаете их параллельно. Таким образом, можно было бы передать некоторые из этих задач веб-воркерам.

Какие задачи можно поставить в веб-воркер? Ничего не связанного с DOM.

Какие задачи можно поставить в веб-воркер? Ничего не связанного с DOM.

@marcelklehr , я не думаю, что веб-работники

Например, мы можем избежать удаления всей строки DOM и повторной вставки новой при каждом нажатии клавиши ( см. Пункт 5 ). Код должен быть достаточно умным, чтобы знать, когда вы вводите диапазон, которым вы уже «владеете», чтобы ему не приходилось выполнять дополнительную работу. Я предполагаю, что текущий код был написан именно так, потому что он был простым и последовательным; он просто не был оптимизирован. Однако может случиться так, что некоторые другие работы по редизайну могут помочь избежать необходимости делать такого рода специальные оптимизации вообще. Было бы полезно, если бы первоначальный автор этого кода мог комментировать, но он / она может быть недоступен.

Мы мало что можем сделать (без редактирования кода webkit) для улучшения самого кода макета (обратите внимание, что у Firefox нет такой же проблемы), но частоту макетов можно уменьшить.

Какая помощь нужна, чтобы сделать этот шаг?

@nemobis , должно быть выдвинуто предложение, которое изменило бы часть дизайна основного редактора, чтобы избежать лишних макетов и сократить количество используемых элементов DOM до чего-то более масштабируемого. Чтобы решить проблему должным образом, вероятно, необходимо проделать приличный объем работы по рефакторингу того, как работает главный редактор, и сохранению авторства в DOM. За самим кодом сложно следить, и его необходимо реорганизовать и лучше прокомментировать, чтобы варианты дизайна (и связанные с этим ограничения) были хорошо понятны.

ладно. Имеет смысл.

@dlongley, кто оригинальные авторы? Могут ли они быть добавлены к этому билету?

Большая часть этого кода унаследована от исходного стека Etherpad, поэтому я бы предположил, что, вероятно, не @nemobis.

@nemobis , что сказал @JohnMcLear ... Я так и

@dlongley Может быть, у вас скоро будет время для обзора?

@JohnMcLear , я думаю, что есть некоторые области, которые нужно изучить для улучшения ситуации (как указано в https://github.com/ether/etherpad-lite/issues/1763#issuecomment-27576051), к сожалению, маловероятно, что я ' У меня лично будет много времени, чтобы обратиться к ним не раньше следующего года. В этом году у меня есть несколько дедлайнов по другим проектам.

Еще кое-что, что могло бы сделать сообщество здесь, - это упорно лоббировать исправление этих ошибок:

https://code.google.com/p/chromium/issues/detail?id=423170
https://code.google.com/p/chromium/issues/detail?id=138439
https://bugs.webkit.org/show_bug.cgi?id=92594

Их исправление может привести к повышению производительности Chrome наравне с Firefox. В конечном счете, было бы лучше решить вышеупомянутые проблемы дизайна, но исправление этих ошибок blink / webkit может иметь большое значение для повышения производительности.

Из этой первой ошибки хрома - см. Эту скрипку: http://jsfiddle.net/eJeQC/

Я почти уверен, что та же проблема (по той же причине), которую мы видим здесь, с etherpad. Обратите внимание, что это быстро в Firefox (предупреждения с ~ 0 мс при нажатии в области результатов) и очень медленно в Chrome (~ 100 мс +, в зависимости от оборудования).

@dlongley Если честно, в следующем году все будет хорошо, нам комфортно, что все идет медленно, потому что стоит исправить все на месте.

@dlongley Привет, парень, просто интересно, было ли у тебя время еще раз изучить это? :)

Я все еще ограничен во времени. Тем не менее, я думаю, что правильным подходом к решению этой, возможно, ряда других ошибок и улучшения состояния обслуживания было бы следующее:

1. Перепишите основной редактор, используя новую версию Ace . Я думаю, что etherpad-lite должен иметь больше отношений на основе зависимостей с Ace (установка через модуль, а не то, что кажется сильно модифицированным чек-ином очень старой версии (2009 г.)). Это позволило бы нам извлекать исправления из Ace независимо от etherpad-lite и избавиться от множества ошибок, связанных с обслуживанием, уменьшить базовый размер кода etherpad-lite, ограничить проблемы, связанные с добавленной стоимостью etherpad-lite, и, следовательно, упростить задачу для разработчики и т. д.
2. Основной дизайн Etherpad-lite должен заключаться в отслеживании, хранении и передаче изменений в документе Ace (от нескольких пользователей), не более того. Поверх ядра должен быть тот же набор функций, который существует сейчас (основные элементы пользовательского интерфейса, выбор цветов, история просмотра и т. Д.; Надеюсь, изменение ядра не потребует от нас вносить слишком много изменений в другом месте). Короче говоря, после переписывания ядра у нас все еще должны быть все функции и ощущение, подобное тому, что было раньше, но объем ядра будет соответствующим образом ограничен, код будет легче понять, и мы могли бы сосредоточиться на etherpad-lite вместо того, чтобы беспокоиться о самом редакторе.
3. Поскольку у меня всегда мало времени, я лишь кратко рассмотрел API-интерфейсы Ace, но похоже, что первый вариант редизайна будет включать в себя создание сеанса EditSession, который отслеживал изменения, передавал их на сервер и получал изменения от других пользователей. с сервера. Каждый пользователь просто получит свой собственный EditSession для документа. Изменения будут сериализованы в / из JSON и, по крайней мере, кажется, могут быть применены как набор изменений с помощью простого вызова applyDeltas в общем документе . Я не изучал все, что входит в объект изменения Ace или что etherpad-lite в настоящее время сериализует для изменений; нам может / может не потребоваться обновлять формат или писать что-то для преобразования устаревших планшетов. Нам все еще нужен способ оставить метатеги на элементах, которые были изменены при применении каждой дельты (для раскрашивания для разных пользователей), но, возможно, здесь также можно сделать что-то простое / умное. Я не смотрел на это; возможно, есть даже способ злоупотребить настраиваемым выделителем синтаксиса, чтобы добиться этого.

Есть и другие детали, которые нужно проработать, но это лишь отправная точка для рассмотрения редизайна, который освободит etherpad-lite от его старой и, казалось бы, неподдерживаемой базовой кодовой базы. Надеюсь, новое ядро ​​можно спроектировать на гораздо более высоком уровне абстракции, как было предложено выше, делегируя всю обработку входных событий, рендеринг, возня с диапазонами и т. Д. Ace. Я думаю, что такое переписывание ядра, вероятно, лучший подход к долгосрочному здоровью etherpad-lite. И может оказаться, что это на самом деле самый простой способ решить эту проблему «черной дыры».

Я хотел бы в какой-то момент сделать это сам, но если есть кто-нибудь, кто сможет это сделать до меня, во что бы то ни стало, пожалуйста, сделайте это. Я также отвечу на комментарии и дам обратную связь / помощь по дизайну, если можно, если кто-то еще захочет над этим поработать.

Я обратился к

@dlongley RE 1 см. http://etherpad.googlecode.com/hg/trunk/infrastructure/ace/README - эти два понятия не связаны. Редактор ACE и Ajax.

@JohnMcLear , а, теперь я это вижу (см. Также: https://groups.google.com/forum/#!topic/etherpad-lite-dev/0uU_LXp_iPg). Казалось, что, возможно, мы просто использовали очень устаревшую версию. Возможно, нам стоит подумать о переходе на редактор ACE c9. Мне нужно будет провести дополнительное исследование различий; В конечном итоге конечной целью было перенести все редактирование, обработку низкоуровневых событий и т. д. в другой пакет и позволить etherpad-lite сосредоточиться на отслеживании и синхронизации изменений от нескольких пользователей в одном документе в реальном времени. Прямо сейчас etherpad-lite требует, чтобы мы занялись разработкой низкоуровневого редактора, и было бы огромным улучшением, если бы этого можно было вообще избежать.

Итак, хотя я не рассматривал различия между редактором ACE c9 и (ACE - A ppJet C ode E ditor), я знаю, что ACE c9 довольно современен, активно поддерживается и, похоже, имеет API, которым мы можем воспользоваться. of для реализации функций etherpad-lite на более высоком уровне абстракции.

c9 ACE не использует contentEditable, мобильная поддержка тоже не работает. :(

Похоже, что мобильной поддержки все еще не хватает, несмотря на невероятный интерес к этому вопросу: https://github.com/ajaxorg/ace/issues/37

Тем не менее, я думаю, что etherpad-lite станет обслуживаемым только в том случае, если мы удалим все основные низкоуровневые элементы редактирования и будем полагаться на другой популярный проект / модуль для этого. Если мобильная поддержка мешает, то мы должны либо посмотреть, можем ли мы помочь добавить ее в ACE, либо выбрать другой редактор в качестве зависимости.

ACE имеет отличную производительность, популярен (== хорошее обслуживание) и имеет хороший API. Мы можем проверить, как другие редакторы совпадают, но мы должны избегать проектов, в которых нет сильных сообществ вокруг них или которые требуют значительного пользовательского низкоуровневого кода редактирования для реализации основных функций etherpad-lite. Основные ошибки редактирования, такие как эта, в частности, не должны попадать в сферу деятельности etherpad-lite.

Если etherpad-lite этого еще не делает, у него также должен быть четкий разрыв между тем, как он сохраняет / сериализует изменения в документах, и редактором, который он использует. IOW, должен быть простой уровень перевода, который преобразует сериализованные изменения в / из любого редактора, который мы в конечном итоге используем. Мы должны иметь возможность менять редакторы, если это необходимо, с как можно меньшим количеством изменений. Это просто идеал; это может быть не так легко достижимо.

На данный момент у меня еще мало времени. Тем не менее, я рассматриваю правильный способ решения этой проблемы, возможно, некоторые другие ошибки, и поддержание технического обслуживания в лучшем состоянии будет:

1. Перепишите основной редактор с новой версией Ace . Я думаю, что etherpad-lite должен иметь более зависимые отношения с Ace (установка через модули, а не сильно измененная регистрация для очень старой версии (2009 г.)).Таким образом, мы можем получать исправления от Ace независимо от Acepad-lite, удалять большое количество ошибок, связанных с обслуживанием, уменьшать размер базы кода Etherpad-lite и ограничивать внимание дополнительными возможностями etherpad- lite Чтобы упростить работу разработчикам и т. д.
2. Основной дизайн Etherpad-lite должен вращаться вокруг (от нескольких пользователей) отслеживания, хранения и передачи изменений в документы Ace, не более того. Над ядром должен быть тот же набор функций, который существует сейчас (базовое содержимое пользовательского интерфейса, выбор цветов, история просмотра и т.д .; надеюсь, что изменение ядра не потребует от нас слишком много изменений в другом месте). Короче говоря, после переписывания ядра мы все равно должны иметь все функции и чувствовать себя похожими на предыдущие, но объем ядра будет соответствующим образом ограничен, код будет легче понять, и мы можем сосредоточиться на функциях etherpad-lite, Не беспокоясь о самом основном редакторе.
3. Поскольку я всегда занят, я только кратко представил Ace API, но кажется, что первым шагом в редизайне является создание EditSession для отслеживания изменений, передачи изменений на сервер и получения изменений от других пользователей с сервера. Каждому пользователю нужно только получить свой собственный EditSession для документа. Изменения будут сериализованы в JSON или из него, по крайней мере, кажется, что его можно использовать как набор изменений с простым вызовом общего документа через applyDeltas . Мы можем (а может и не потребовать) обновить формат или написать что-нибудь для преобразования старой клавиатуры. Я не изучал это; может быть, есть даже способ злоупотребить специальным выделителем грамматики, чтобы добиться этого.

Необходимо решить больше деталей, но это только отправная точка для рассмотрения редизайна, который может освободить etherpad-lite от его старой, казалось бы, неподдерживаемой базовой кодовой базы. Есть надежда, что новое ядро ​​может быть спроектировано как более высокий уровень абстракции, как описано выше, и вся обработка входных событий, рендеринг, путаница в области видимости и т. Д. Могут быть делегированы Ace. Я думаю, что это переписывание ядра может быть лучшим способом сохранить работоспособность etherpad-lite в долгосрочной перспективе. Более того, оказывается, что это на самом деле самый простой способ решить эту проблему «черной дыры».

Я хочу сделать это сам в какой-то момент, но если кто-то может сделать это до меня, пожалуйста, сделайте это. Если кто захочет, я также отвечу на комментарии и предоставлю отзыв / помощь по дизайну.