2016-07-05 3 views
1

Итак, у меня есть раздел во внутреннем приложении, который позволяет пользователям изменять/редактировать HTML через Summernote.JS.Эхо вызывает медленную работу с большой строкой

Проблема, с которой я сталкиваюсь, - это смешное время загрузки, которое я, похоже, испытываю только в Chrome.

Содержимое HTML, которое редактируется, имеет длину 150252, так как есть встроенные изображения base64. Время загрузки являются ..

Chrome (Version 51.0.2704.106 m):    39.53 seconds 
Firefox (Version 43.0.1):      2.08 seconds (onload: 2.74s) - 629.8KB 
Internet Explorer (Version 11.0.9600.17843): ~2.8 seconds 

Ниже приводится образ времени загрузки Chrome на полном обновлении.

Chrome Load


Самое смешное, когда я удалить эхо выше содержания, мгновенно

<textarea id="content" name="content" placeholder="Simply enter the section content below.."><?php echo $this->section->section; ?></textarea> 

Теперь я нашел загрузку страницы-х это old bug on PHP.net (после некоторого серьезного поиск lol), в котором говорится, что эхо PHP обрабатывает буферизацию данных в браузере через TCP/IP ОЧЕНЬ плохо из-за Nagle Algorithm.

Не удалось сохранить содержимое во временный файл и использовать readfile() для получения содержимого (которое возвращает исходное представление), что еще я могу сделать, чтобы исправить эту проблему в chrome? Вырезать выходные данные? Без чрезмерного усложнения процесса.

+0

Это проверка орфографии хром, которую вы можете обвинить. Отключить его (в настройках -> языки -> язык и настройки ввода -> флажок внизу) и сказать, есть ли разница в производительности? – zerkms

+0

@zerkms только предельное увеличение производительности - тесты варьируются от '22 секунд' -' 34 секунды' – Darren

+1

@zerkms Оказывается - это ошибка Chrome, когда длина строки/строки длиннее, чем '2^16', что приводит к плохому преобразованию Посмотреть – Darren

ответ

1

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

Теперь, чтобы подробно остановиться на этом вопросе, изучив его. Оказывается, у Chrome была эта ошибка в Chromium (Reference (Issue #69227)) в течение некоторого времени. Так как изображение base64 находится в одной строке, предел диапазона одиночной линии хрома составляет 2^16, который превысил мое изображение base64.

Прерывание изображения в новых строках здесь и там после определенных ограничений символов позволило сбросить время загрузки с ~34 seconds до ~17 seconds. Я создал функцию, подобную этой, которая расщепляет строку соответствующим образом:

function __chunk($string, $chunkSize = 40) { 
    $splitString = str_split($string, $chunkSize); 

    foreach($splitString as $chunk) { 
     echo $chunk . "\n"; 
    } 
} 

будет, очевидно, придется выяснить соответствующий $chunkSize.

Трюк заключается в том, чтобы просто выяснить, как извлечь данные base64, поскольку остальная часть содержимого HTML делает то, что ему нужно.

Другим альтернативным решением было бы преобразовать упомянутый base64 в blob (Reference SO Question).

Вы можете получить более полное представление об этой ошибке, проверив this bug, найденный в Atom, который относится к этой точной проблеме.

Смежные вопросы