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

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

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

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

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

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

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


sql sql-server-2008 sql-server-2005 sqlcachedependency
person Kjartan Þór Kjartansson    schedule 13.03.2009    source источник
comment
Вы нашли ответы? Я бы тоже хотел знать ответ на этот вопрос.   -  person niaher    schedule 24.07.2009
comment
Я сожалею о том, насколько устаревшим стал этот вопрос, но консенсус в отношении проекта заключался в том, чтобы пойти другим путем, поэтому мы сами так и не получили каких-либо четких результатов. Однако то, что я прочитал в ответах ниже, содержит важную информацию по этим вопросам, я не думаю, что могу дать много правильных ответов, потому что я думаю, что все ответы на сегодняшний день на самом деле верны, хотя у меня нет никаких результатов для Поддержите это внутреннее чувство.   -  person Kjartan Þór Kjartansson    schedule 12.07.2010

Ответы (5)


arrow_upward
7
arrow_downward

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

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

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

Внутри:

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

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

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

person Rasshme Chawla    schedule 25.03.2010

arrow_upward
4
arrow_downward

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

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

person Mladen Prajdic    schedule 21.07.2009
comment
Поскольку проект был связан с несколькими одновременными подключениями к таблицам, которые могли нарушить эту передовую практику, которую вы изложили, и я склонен полагать, что вы правы в своей оценке. - person Kjartan Þór Kjartansson; 12.07.2010

arrow_upward
2
arrow_downward

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

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

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

person Fabio Milheiro    schedule 10.10.2009

arrow_upward
1
arrow_downward

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

person mrdenny    schedule 31.03.2009
comment
Да, это инструкции по настройке зависимости кеша, но проблема не в этом. Вопрос в снижении производительности SQL-операций при большом количестве запросов к chache. В этой статье, к сожалению, нет никакой информации об этом. :-( - person Kjartan Þór Kjartansson; 06.04.2009

arrow_upward
1
arrow_downward

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

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

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

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

person Brad Bell    schedule 10.08.2009