Лучше многие небольшие запросы ajax или большой для глобальной производительности сайта?

У меня есть сайт wordpress с полем поиска ajax, который возвращает список сообщений с указанием названия, URL-адреса, даты и категории.

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

Мое сомнение заключается в следующем: хорошо ли сделать другой запрос каждый поворот страницы, или сделать только один запрос, чтобы получить все сообщения, а затем управлять разбиением на страницы через javascript (ответ я JSON)?

Лучше ли делать более частый небольшой запрос с легким ответом или большой?

Я полагаю, что в начале жизни сайта первое решение является лучшим. Я не уверен в масштабируемости по мере роста сайта.

Как вы думаете?

ОБНОВЛЕНИЕ: я получил пару очень хороших ответов, были проблемы с интерфейсом пользователя.

Hwr Я бы хотел, чтобы вы больше сосредоточились на производительности. Мой сайт находится на общем сервере, но мы ожидаем, что трафик будет расти быстрыми темпами, так как сайт получит международный доступ. Мой страх в том, что Wordpress не сможет справиться с увеличенными накладными расходами, которые исходят из запросов ajax.

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

Учитывая, что не все пользователи, я полагаю, собираются проверить все страницы результатов, я предполагаю, что первый...

Ответ 1

Правильный ответ: "Это зависит".

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

Затем вы можете асинхронно заполнить дополнительные обратные страницы и соответствующим образом обновить элементы управления "итоговыми страницами".

Оттуда ваш пользователь имеет немедленные результаты и имеет возможность переключаться между всеми вашими данными в 2-х секундных секундах.

Если у вас был сайт, на котором вам были доступны все ваши данные сразу, и у вас было 40 результатов, которые нужно было показать, затем перейдите с большой дамбой.

Если у вас был сайт с бесконечной прокруткой, вы бы захотели захватить пару длин страниц. Для чего-то вроде Twitter, я бы, вероятно, предварительно вычислил среднюю высоту контейнера по сравнению с высотой экрана. Затем я загрузил три или четыре экрана с твитами. Оттуда, когда пользователь прокручивался на свой 2-й или 3-й экран (или 3-й или 4-й соответственно), я загрузил следующую партию.

Итак, мое событие может быть привязано к onscroll, который проверяет, разрешено ли ему запускаться (если он был не менее 16 мс с момента последнего запуска, - очевидно, мы все еще прокручиваем), тогда он проверяет, где это с точки зрения того, насколько близко к дну, учитывая высоту экрана и общую высоту последней партии (screen_bottom >= latest_batch.height * 0.75) или аналогичную. Экземпляр screen_bottom будет относиться к last_batch, в том случае, если пользователь прокручивал назад, выше предыдущей партии, screen_bottom был бы отрицательным числом, полностью.

... или нормализовать их, так что вы просто имеете дело с процентами.

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

Итак, выясните, что такое счастливая среда, основанная на том, что вы делаете, и как вы ожидаете, что пользователь будет использовать ваши данные.

Ответ 2

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

Нет общего ответа, это сильно зависит от вашего приложения и шаблонов поиска ваших пользователей. В общем, я бы сделал простейшую вещь, которая выполняет эту работу, но также контролирует взаимодействие с пользователем (например, ведение журнала запросов и размеров результатов), производительность сайта (например, через время загрузки Google Analytics) и загрузку сервера (например, через munin ) на твоей странице. Если у вас возникнут проблемы, вы можете оптимизировать свое приложение с этого момента - и к этому времени у вас будет намного лучшее понимание ваших пользователей и вашего приложения.

Ответ 3

Хорошо, в первую очередь. Если ваш AJAX создает те же сообщения, что и обычные создаваемые pageload, вы можете имитировать pageload. Т.е., запросите кучу сообщений (например, страницу с большим количеством сообщений), отправьте ВСЕ их данные в JS и позвольте ей обрабатывать разбиение на страницы.

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

Если вы хотите оптимизировать свой сайт, установите плагин кеша. Он будет кэшировать в HD все запросы БД, а затем использовать эти файлы, чтобы снова делать такие же запросы.