Как реализовать обновления в реальном времени в ASP.NET - PullRequest
2 голосов
/ 27 февраля 2010

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

  • Веб-сайт биржи акций, который показывает цены на акции в режиме реального времени
  • Отображение данных типа "Что другие пользователи ищут в настоящее время .."

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

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

Ответы [ 3 ]

0 голосов
/ 27 февраля 2010

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

0 голосов
/ 27 февраля 2010

Проблема касается многих слоев веб-приложения.

На клиенте вы используете либо iframe, содержимое которого автоматически обновляется каждые n секунд с использованием тега meta refresh (HTML), либо javascript, который запускается таймером и обновляет именованный div (AJAX).

На сервере у вас есть как минимум два места для кэширования ваших данных:

Один из них находится в объекте Application, где вы сохраняете метку времени последнего обновления и обновляете кэшированные данные по истечении интервала обновления.

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

0 голосов
/ 27 февраля 2010

Это не обязательно сделано в БД. Как вы предположили, это дорого. Хотя БД может быть резервным хранилищем, вероятно, для сопровождения операции опроса используется более эффективный механизм, такой как сохранение статуса в реальном времени в памяти в дополнение к окончательному состоянию на БД. Вы можете опрашивать память намного эффективнее, чем ВЫБРАТЬ состояние из таблицы каждую секунду.

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

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

(оптимизация для использования меньшего количества ресурсов БД в реальном времени)

Вместо того, чтобы опрашивать базу данных для каждого пользователя, чтобы проверять состояние задания каждые X секунд, немного измените поведение ситуации. Каждый раз, когда работа добавляется в базу данных, читайте базу данных один раз, чтобы поместить метаданные о всех работах в кеш. Так, например, кэш памяти будет отражать [user49 ... user3, user2, user1, userCurrent] 50 заданий пользователя, если по 1 заданию каждое. (Может быть, я должен был написать это как [job49 ... job2, job1, job_current], но та же идея)

Тогда веб-страницы отдельных пользователей будут опрашивать этот кеш, который всегда остается актуальным. В этом примере БД была прочитана только 50 раз в кеш (один раз за отправку задания). Если эти 50 пользователей ждут в среднем 1 минуту для обработки задания и опрашивают статус каждую секунду, тогда база пользователей опрашивает кэш в общей сложности 50 пользователей x 60 секунд = 3000 раз.

Это 50 операций чтения из базы данных вместо 3000 за период в 50 минут. (в среднем по одному в минуту). Кэш-память всегда свежая и обрабатывает нагрузку. Это гораздо менее страшно, чем рассматривать возможность попадания в БД каждую секунду для каждого пользователя. Вы можете хранить другие статистические данные и информацию в кэше, чтобы помочь с оценкой и тому подобное. Пока свежий кеш обеспечивает большую эффективность, он является жизнеспособной альтернативой массовым попаданиям в дб.

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

Другое примечание: БД будет знать, когда будет добавлена ​​другая запись задания, независимо от того, откуда, поэтому триггер может инициировать обновление кэша.

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

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