Подтвердить что ты не робот

Вопросы производительности для зависимости кэша SQL

Я работаю над проектом, в котором мы думаем использовать SQLCacheDependency с SQL Server 2005/2008, и нам интересно, как это повлияет на производительность системы.

Итак, мы задаемся вопросом о следующих вопросах.

Может ли число объектов SQLCacheDependency (уведомления о запросах) отрицательно влиять на производительность SQL Server, т.е. на операции вставки, обновления и удаления в затронутых таблицах?

Какой эффект (с точки зрения производительности) будет, например, 50000 различных уведомлений о запросах в одной таблице в SQL Server 2005/2008 при вставке и удалении в этой таблице.

Есть ли рекомендации по использованию SQLCacheDependencies? Любое официальное лицо делает и не делает этого? Мы нашли некоторую информацию в Интернете, но не нашли информации о последствиях для производительности.

Если есть кто-нибудь, у кого есть ответы на эти вопросы, это было бы здорово.

4b9b3361

ОТВЕТЫ

Ответ 1

Зависимость SQL Cache с использованием механизма опроса не должна быть нагрузкой на сервер sql или сервер приложений.

Давайте посмотрим, что все шаги для работы sqlcachedependency для их работы и анализа:

  • База данных включена для sqlcachedзависимости.
  • В таблице указано, что "Employee" включен для sqlcachedзависимости. (может быть любое количество таблиц)
  • Web.config обновлен, чтобы включить sqlcachedзависимость.
  • Страница, в которой настроена настройка кэша sql. thats it.

внутри

  • шаг 1. создает таблицу "ASPnet_sqlcachetablesforchangenotification" в базе данных, которая будет хранить имя таблицы "Сотрудник", для которой включена поддержка sqlcachedзависимости. и добавьте некоторые хранимые процедуры.
  • шаг 2. вставляет запись таблицы "Сотрудник" в таблицу "ASPnet_sqlcachetables forchangenotification". Также создается триггер удаления обновления вставки в этой таблице "Сотрудник".
  • шаг 3. Включает приложение для sqlcachedзависимости, предоставляя строку соединения и время опроса.

всякий раз, когда в таблице "Сотрудник" происходит изменение, запускается триггер, который заново обновляет таблицу "ASPnet_sqlcachetables forchangenotification". Теперь приложение опроса базы данных говорят каждые 5000 мс и проверяет любые изменения в таблице "ASPnet_sqlcachetablesforchangenotification". если есть какие-либо изменения, соответствующие кеши удаляются из памяти.

Большое преимущество кеширования в сочетании со свежестью данных (максимальные данные могут быть застывшими на 5 секунд). Опрос берет на себя фоновый процесс, который не должен быть препятствием для работы. потому что, как вы видите из списка выше, задача минимальна для процессора.

Ответ 2

SQLCacheDependency реализуется как индексированное представление, и каждый раз, когда таблица изменяется, этот индекс изменяется. так много представлений (объекты SQLCacheDependency) в одной таблице означают полный успех для модификаций. однако, если у вас есть 1 просмотр (объект SQLCacheDependency) для каждой таблицы, у вас не должно быть проблем.

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

Ответ 3

Вы правы, не так много информации об этом, но есть фраза, связанная с вашим вопросом на этой странице http://msdn.microsoft.com/en-us/library/ms178604%28VS.80%29.aspx

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

Надеюсь, это поможет вам, хотя ваш вопрос уже немного стар.

Ответ 4

У этой страницы есть какая-то хорошая информация о настройке, какая техника используется хорошо (если бы я просто ее снял).

Ответ 5

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

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

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

Как всегда, ваш пробег может меняться.