таблица JavaScript, sorting/paging (клиентский). Как большой является слишком большим?

Я использую плагин jQuery под названием Tablesorter, чтобы сделать клиентскую сортировку таблицы журнала в одном из моих приложений. Я также использую tablepager дополнение.

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

Однако я вижу, что, вовремя, журнал, который я отображаю, мог стать довольно большим. Я уверен, там прибывает точка, где клиентская подкачка страниц и сортировка будут непрактичными. Какую точку эта техника начнет сворачивать под своим собственным весом? 500 записей? 2 000 записей? 10 000 записей?

Править: В ореховой скорлупе, какие критерии Вы использовали бы, чтобы определить, собираетесь ли Вы использовать клиентскую сортировку/подкачку страниц в противоположность подкачке страниц серверной стороны? Размер ожидаемого фактора набора результатов в Ваше решение? Где переломный момент?

7
задан Aheho 18 June 2010 в 01:30
поделиться

3 ответа

Однако я вижу, что со временем журнал, который я отображаю, может вырасти довольно большим. Я уверен, что наступит момент. когда пагинация и сортировка на стороне клиента станут непрактичными. В какой момент когда эта техника начнет разрушаться под собственным весом? 500 записей? 2000 записей? 10 000 записей?

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

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

3
ответ дан 7 December 2019 в 03:11
поделиться

Несколько сотен, вероятно, нормально, в зависимости от количества столбцов. Это наверняка сломается, когда вы будете иметь дело с данными порядка 10 ^ 3 (тысяч).

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

3
ответ дан 7 December 2019 в 03:11
поделиться

Этот метод, вероятно, потерпит неудачу, когда браузер или клиентский хост не сможет его принять.

Используйте нумерацию страниц на стороне сервера, чтобы предотвратить это.

Сначала я хотел бы рассмотреть объем данных, которые я отправляю клиенту, что, в свою очередь, вызывает фактор времени загрузки.

Скажем, если каждая строка таблицы составляет 200 байтов, и я отправляю клиенту 10000 строк (что позволяет выполнять сортировку и разбиение на страницы), я отправляю 200 * 10000 = 2000000 байтов, или 2 МБ. Браузеру потребуется некоторое время, чтобы загрузить его с сервера, затем некоторое время плагину сортировки, чтобы отсортировать все, а затем разбить его на страницы.

Фактически, нагрузка на ваш сервер увеличится из-за необходимости отправлять ВСЕ строки клиенту.

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

Если вы используете сортировку на стороне сервера + разбиение на страницы, клиент видит точную и актуальную информацию. Также скажем, что у вас те же 10000 строк, каждая по 200 байтов.У вас 20 строк на странице. Вы отправляете только 20 * 200 = 4000 байтов, что составляет 4 КБ, относительно мало и может обрабатываться браузером / сервером.

3
ответ дан 7 December 2019 в 03:11
поделиться
Другие вопросы по тегам:

Похожие вопросы: