Постоянно запрашивать сервер через Javascript - хорошая идея?

Question

У меня есть небольшой сайт с 5-10 администраторами. Я настроил его на мониторинг того, что делает каждый администратор (добавление элементов, удаление элементов и т. Д.). У меня был список в нашей админ-панели, который показывает предыдущие 10 действий, выполненных коллективной администрацией. Сегодня я решил делать это самообновление каждые 30 секунд.

Мой вопрос прост: есть ли проблемы с этим? Я вызываю небольшой фрагмент текста с каждым запросом, и, скорее всего, запрос выполняется только на 3 или 4 компьютерах одновременно (что отражает количество одновременно зарегистрированных администраторов).

  $(document).ready(function(){
    setInterval("activity()", 30000);
  });

  function activity() {
    $("#recent_activity").load("../home/login #recent_activity .data");
  }

Производит следующее (или подобное - только с 10 строками) с каждым запросом.

<table>
  <tbody>
    <tr>
      <td><p>jsampson</p></td>
      <td><p>logged out</p></td>
      <td><p>28 minutes 27 seconds ago</p></td>
    </tr>
    <tr>
      <td><p>jdoe</p></td>
      <td><p>logged in</p></td>
      <td><p>29 minutes 45 seconds ago</p></td>
    </tr>
  </tbody>
</table>

Answer 1

Вы должны кешировать это и обновлять кеш каждые 30 секунд.

Answer 2

3-4 пользователя каждые 30 секунд - это совсем немного. Даже 300 пользователей с такой скоростью совсем не будут такими.

Вы можете проверить эти вопросы:

• Должен ли я использовать Ajax Push или Pull
• Пример кода простого длинного опроса

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

Answer 3

На мой взгляд, это не проблема. Сайты, работающие в гораздо большем масштабе (например, Betfair), используют сотни вызовов xhr в минуту для каждого подключенного клиента. Очевидно, что они имеют гораздо большую аппаратную инфраструктуру, но браузер отлично справляется.

У меня есть сайты, которые используют меньший интервал, и они масштабируются до нескольких сотен одновременных пользователей, работающих с веб-сервера sinlge.

Answer 4

Нет, не должно быть никаких проблем. Я делаю то же самое с интервалом в 1 минуту для системы уведомлений, которую я написал на интранет-портале моей компании. Честно говоря, любой веб-сервер должен справиться с этим.

Это действительно не хуже (на самом деле, значительно лучше), чем они, скажем, обновляют свой браузер каждые 30 секунд ... Учитывая значительно меньшую скорость передачи данных, это, вероятно, будет в 10-20 раз лучше обновляя его ... или примерно одинаковую пропускную способность обновления каждые 5-10 минут. : -)

Answer 5

Я думаю, то, что вы сделали, прекрасно.

Если бы я занимался этим проектом, я бы начал с того, что у вас есть, и добавил бы событие setTimeout (), чтобы увеличивать отображение минут / секунд каждую секунду.

Пользователи будут воспринимать отображение в режиме реального времени, и они, вероятно, никогда не нажмут обновление страницы.

Опасность обновления только каждые 30 секунд в том, что некоторые люди будут рефлексивно нажимать на обновление для «последних» каждый раз, когда обращают на это внимание.

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

Answer 6

Существует несколько различных способов эмулировать пересылку сервера по HTTP. Такие техники недавно получили причудливое название: Комета .

Если конфигурация вашего сервера допускает неограниченное выполнение сценариев, вы можете использовать iframe для реализации панели и использовать фрагментированные передачи (например, через PHP flush()) для создания постоянного HTTP-соединения. Такое решение должно иметь наименьшие издержки, если интервал времени между последовательными сообщениями короткий. Для длительных интервалов предпочтительным является опрос на стороне клиента, поскольку не требуется поддерживать TCP-соединение.

Answer 7

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

При этом, если вас беспокоит объем данных, которые отправляются обратно, вы всегда можете сделать так, чтобы вызов отправлял обратно простой флаг, ЕСЛИ есть новые данные, а затем продолжайте извлекать данные, если это так.

Но да, с таким количеством пользователей у вас не должно возникнуть проблем. Настраиваемая доска объявлений на основе RoR, которую я часто использую, использует похожую технику, чтобы увидеть, обновлялись ли потоки, пока вы читаете, и более 100 пользователей одновременно нажимают на нее без проблем.

Answer 8

То, что многие пользователи не собираются сбивать ваш сервер.

Если вы действительно беспокоитесь о производительности, я дам вам 2 совета:

• Используйте JSON для отправки данных клиенту, он будет легче отформатированного HTML.

• Используйте фиксированную дату для данных истории и вычислите относительное время на клиенте, это позволит вам кэшировать данные истории.

  {"user":"jsampson","action":"logged out","date":"20090622T170822"}

Answer 9

Вы видели Google Wave превью ...? Для такого небольшого числа это не проблема, тем более что администраторы об этом узнают. (Это не значит, что вы накладываете некоторую нагрузку на процессор или мобильное интернет-соединение какого-либо посетителя.)

Answer 10

Взвесьте это против альтернативы. Если бы каждый пользователь обновлял страницу каждые 30 секунд, загружая всю страницу, объем обработки на стороне сервера и генерируемый трафик были бы намного больше, чем просто обновление «интересных частей».

Для этого и создан AJAX.