Производительность Http-много небольших запросов или один большой
сценарий:
- на моем сайте я показываю книги.
- пользователь может добавить каждую книгу в список" читать позже".
поведение:
когда пользователь входит на сайт, ему предоставляется список книг. Некоторые из них уже находятся в списке "читать позже", некоторые-нет.
пользователь имеет указание рядом с каждой книгой, сообщая им, была ли книга добавлена в список или нет.
мой вопрос
Я обсуждаю, какой вариант является идеальным для моей ситуации.
Вариант 1:
- для каждой книги запросите сервер, существует ли он уже в списке пользователя.
- обновить индикатор для каждой книги.
Pro: Очень маленький запрос на сервер и очень простой ответ (true или false).
Con: на странице с 30 книги, я отправлю 30 отдельных http-запросов, которые могут блокировать сокеты, и довольно медленно, учитывая, что браузер и сервер должны выполнять все рукопожатия для каждой транзакции.
Вариант 2:
- я запрашиваю сервер один раз и получаю ответ с полным списком книг в списке "читать позже" в виде массива.
- в браузере я просматриваю массив и обновляю указание для каждой книги на основе того, существует ли она в массив или нет.
Pro: Я делаю только один запрос и обновляю индикатор для всех книг сразу.
Con: в списке "читать позже" могут быть сотни книг, и передача большого массива может оказаться медленной и чрезмерной. Особенно в сценариях, когда на экране появляется не 30 книг, а всего 2-3. (То есть, я хочу проверить, есть ли в списке определенная книга, и для этого у меня есть сервер, отправляющий клиенту весь список книг из список.)
и
какой путь вы бы пошли, чтобы максимизировать производительность: 1 или 2?
есть ли альтернатива мне не хватает?
3 ответов
Вариант 1 звучит хорошо, но имеет большую проблему с точки зрения масштабируемости.
Вариант 2 смягчает эту проблему масштабируемости, и мы можем улучшить ее дизайн:
клиентская сторона через javascript собирает только отображаемые идентификаторы книг и запрашивает один раз через ajax массив информации для чтения позже, только для этих 30 книг. Таким образом, вы по-прежнему быстро обслуживаете страницу и запрашиваете небольшой набор дополнительной информации, один раз с одним http-запросом.
серверная сторона вы можете дальше улучшите кэширование массива идентификаторов чтения в памяти для каждого пользователя.
Я думаю, что в 2017 году решение меньше связано с общей производительностью, но с пользовательским опытом и ожиданиями пользователей.
и в настоящее время пользователь не терпит задержек. В этом смысле сложные пользовательские интерфейсы стараются реагировать как можно быстрее. Таким образом: если вы можете использовать эти небольшие запросы, чтобы позволить пользователю что-то сделать (вместо ожидания 2 секунд для этого одного большого запроса), вы должны предпочесть это решение.
слишком мои знания, есть много "High fidelity" сайты там были одна страница может отправляет 50, 100 запросов... Поэтому я считаю, что это обычная практика.
и, возможно, это полезно здесь: se-radio.net эпизод 277 интенсивно обсуждает эту тему в контексте задержки хвоста.
на мой взгляд, это зависит от того, как хранятся данные. Если используется реляционная база данных, вы можете легко получить логический флаг в список книг, просто выполнив соединение в соответствующих таблицах. Это, скорее всего, даст вам лучшие результаты и вам не придется писать алгоритмы на переднем конце.