огромные списки HTML из проблемы производительности JSON

Question

Я создаю своего рода инструмент управления проектами, используя PHP на стороне сервера и jQuery плюс пользовательский MVC в javascript.

У меня есть всплывающее окно, чтобы помочь пользователю добавить людей в проект. Когда он появляется, пользователь должен выбрать группу (скажем, группу студентов), а затем он может выбрать профили, чтобы добавить их в текущий проект.

Я проверил его с группами по 70-120 человек, и он работает с небольшой задержкой.

НО, КОГДА Я ТЕСТИРОВАЛ БОЛЬШУЮ ГРУППУ 1000 ЛЮДЕЙ, время обновления настолько велико, что Хром спрашивает меня, хочу ли я остановить сценарий или подождать больше времени ... Это не приятно для опыта iser !!!

данных происходит от сервера в формате JSON:

{ "пользователи": [{ "UID": "Cortes", "Имя": "Франсуа", "фамилия": "CORTES", "почта" : "..."}],/* 1000 пользовательских записей больше * /}

и форматирование данных в этом формате HTML (Настраиваемый шаблон псевдо Усы)

<li> 
    <div class="wrapper"> 
    <p class="title"> {{firstname}} {{lastname}} {{mail}} </p> 
    <p> {{uid}} </p> 
    <p> <input type="checkbox" id="select-{{uid}}" /> </p> 
    </div> 
</li> 

JQuery используется для создания списка и добавить некоторых слушателей - выбрать/снять выделение из состояния локального хранения до всплывающей проверки - вид выделения на зависающей мыши на каждый элемент списка [код] [код] Мой вопрос: КАК СДЕЛАТЬ ПРОИЗВОДИТЕЛЬНОСТЬ УТЕЧИТЬ И КАК ИСКАТЬ?

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

EDIT: Спасибо за ваши комментарии и ваши сообщения.

Немного больше объяснений: обычно группы занимают 50-200 человек. Группа из 1000 человек - это всего лишь 90% общего, временного и из-за некоторых технических и управленческих соображений. Но это отличный вызов для обеспечения исполнения и обеспечения реактивности пользовательского интерфейса.

На данный момент он терпит неудачу испытания ...

@ Крис: Я строй контроллера тестов в PHP время генерации и размера JSON

@Dandavis: Да, на данный момент я сделай это. Я беру общий шаблон DIV со страницы с jQuery и повторяю 1000 раз по данным JSON, javascript-строку, заменяющую подстановочные знаки {{example-data-name}} своим примером-значением данных, затем я вставляю его в DOM (jQuery), а затем я связываю прослушиватели событий (jQuery тоже) ... Уродливый код, я согласен, но самодельный, и никоим образом и не нужно реорганизовать его с помощью BackBone или Knockout ...

documentFragment? ну ... нужно копать еще больше!

@ ajax81: статические JSON кэшируются при загрузке страницы ??? почему бы и нет ... возможно, самый простой способ изменить существующую работу и усилия!

@Alberto: полезные советы, которые я имею в виду. Как я уже отмечал выше, я начинаю свои тесты сегодня днем ​​

Я чувствую, что PHP делает свою работу правильно (относительно размера данных и скорости генерации), но m настраиваемый подход к шаблонам неэффективен для обработки всех данных!

Нет необходимости разбивать данные на страницы, поскольку пользователь обычно прокручивает список небольших (50) и средних (120) записей. 1000 - стресс-тест. Это происходит только в летний период (праздники), но если я буду успешным, ежедневный опыт пользователя будет лучше и защищен от сбоев в системах с низкой производительностью.

С уважением.

EDIT и решение вопроса

PHP

Я протестированные ТГц PHP скрипт: 1000 извлечения записей и формирование JSON меньше 0,25 секунд времени выполнения и менее 100ko долго ... поэтому никакой конкретной проблемы на стороне сервера.

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

Javascript

Затем я изменил использование шаблонов: теперь цикл из 1000 записей в формате JSON, оценка шаблона и добавления результата в необработанном HTML строки, следующий прикрепление LI элементов в UL.

На данный момент этот список визуально готов для пользователя.

Позже я снова зациклился на данных JSON для привязки обработчиков событий (установите флажок, щелкните по окружающему DIV и наведите указатель мыши на DIV с указателем ...), но список пока отображается!

Задержка при освежающем списке видна, но очень кратковременная, менее 1,5 секунд ... Возможно, я добавлю значок песочных часов, чтобы предотвратить повторный клик пользователя во время ожидания списка.

так синхронизации тест успех В регулярном использовании, списки не будут превышать 150 человек, так что, если это нормально для 1000 ... это нормально для меня :-)

Спасибо много (@ все) для помощи.

Answer 1

Если бы я тебя, я бы следующие шаги:

1. дорожку вниз запрос, который извлекает данные и время его, если это займет много, может быть, это просто отсутствующий индекс, или неэффективный запрос, но на этом этапе вы знаете, где указать свой палец
2. использовать статическую версию этой страницы, не делая никакого вызова на стороне сервера, просто поместить результат JSON в файл и загрузить его, посмотреть, как ведет себя ваш код
3. как @ Крис Питман сказал, сколько времени занимает GET

Вы должны быть в состоянии грубо найти, где проблема, выполнив следующие шаги.

Как правило, я бы посоветовал вам увеличить количество букв, с которых начинается поиск, чтобы вы никогда не возвращали много результатов, тем самым уменьшая время загрузки, также потому, что никто не ожидает, что вы вернете результаты, когда пользователь вводит «a» в поле поиска.

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

Answer 2

Я не знаю точно, что вы хотите, но используете ли вы разбиение на страницы в этом списке json? Перечислите значения с разбиением на страницы 10, 20, 30 строк и т. Д. И дайте серверному вызову ajax захватить следующую партию выгружаемых строк.

Answer 3

Ваша проблема напрямую не связана с отслеживанием «утечки производительности», поскольку вы знаете, где проблема, и вы уже определили виновника: вы обрабатываете гигантское количество данных. Предложение Альберто о передаче более тонкого массива и попытке сделать больше с меньшим - отличное место для начала. Предложение Асе Эны на странице ваших данных очевидно, но (я предполагаю) немного за пределами вашей зоны комфорта.

Если этот список людей часто доступен и используется во всем приложении, предложение Альберто по кешированию списка в его собственном файле JSON является хорошим. Это спасет вас массивный запрос базы данных каждый раз, когда список понадобится, и избавит вас от необходимости делать последующие вызовы ajax для извлечения данных. Кроме того, он будет кэшироваться на компьютере вашего клиента (даже при посещении приложения) и повысить производительность, потому что его не нужно загружать каждый раз, когда они посещают приложение, или каждый раз, когда список должен отображаться. В качестве дополнительного бонуса кеширование всего списка на клиенте значительно упрощает механизм подкачки, который вы будете использовать для передачи данных, потому что вам не нужно будет управлять SQL-сервером на стороне сервера, состоянием сеанса и т. Д.

Редактировать -

Мне пришло в голову, что вы, возможно, не знаете, что я имею в виду, когда говорю «кешировать JSON-файл на клиенте». Вот пример:

<script src="MyPeopleList.json?v1" type="text/javascript"></script> 

Вы в основном просто ссылку на файл JSON точно так же, как и любой другой JavaScript. Список пользователей JSON теперь доступен для остальной части вашего приложения и также кэшируется. Если вам нужно обновить список или убедиться, что ваши пользователи получают самую последнюю версию списка, вы можете просто изменить «v1» на «v2». (версия важна, потому что некоторые разновидности Internet Explorer агрессивно кэшируют эти файлы и не обновляются, даже если файл на сервере более новый, чем тот, который находится в кеше).