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

Question

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

Итак, нас интересуют следующие вопросы

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

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

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

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

Answer 1

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

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

1. База данных включена для sqlcachedependency.
2. Таблица с надписью «Сотрудник» включена для sqlcachedependency. (может быть любое количество таблиц)
3. Web.config обновлен, чтобы включить sqlcachedependency.
4. Страница, на которой сконфигурирована зависимость sql-кэша. вот и все.

Внутренне:

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

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

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

Answer 2

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

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

Answer 3

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

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

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

Answer 4

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

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

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

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

Answer 5

На этой странице , похоже, есть хорошая информация о настройке, какую технику лучше использовать (если я только что ее просмотрел).