Управление производительностью (компонент Service Broker)
Производительность приложения, работающего с компонентом Service Broker, обычно определяется двумя факторами:
- Число сообщений, прибывающих в течение указанного периода времени.
- Скорость, с которой приложение обрабатывает каждое сообщение.
Мониторинг этих двух факторов — ключ к пониманию характеристик производительности приложения.
Компонент Service Broker предоставляет ряд счетчиков производительности, позволяющих получать данные о его действиях. Кроме того, компонент Service Broker регистрирует серьезные ошибки в журнале ошибок SQL Server и журнале событий приложений Windows. Дополнительные сведения о счетчиках производительности, динамических административных представлениях и событиях трассировки для компонента Service Broker см. в разделе Наблюдение за компонентом Service Broker.
Настройка хранимой процедуры компонента Service Broker
Настройка хранимой процедуры, использующей средства компонента Service Broker, практически не имеет отличий от настройки любой другой хранимой процедуры. Однако при этом нужно учитывать несколько дополнительных факторов.
Во-первых, используйте предложение WAITFOR. Сообщения редко прибывают через предсказуемые интервалы времени. Даже в работе службы, к которой сообщения прибывают примерно с той же частотой, с которой хранимая процедура их обрабатывает, бывают периоды, когда доступных сообщений нет. Таким образом, в процедуре следует использовать предложение WAITFOR с инструкцией RECEIVE или GET CONVERSATION GROUP. Без предложения WAITFOR эти инструкции сразу же завершаются при отсутствии сообщений в очереди. В зависимости от реализации хранимой процедуры процедура после этого может начать циклическое выполнение инструкции, напрасно потребляя ресурсы, или завершиться, чтобы повторно активироваться позже, что потребляет больше ресурсов, чем простое продолжение работы.
Непредсказуемость моментов прибытия сообщений можно учесть, используя предложение WAITFOR с инструкциями RECEIVE или GET CONVERSATION GROUP. Если приложение постоянно работает как фоновая служба, не нужно указывать значение времени ожидания в инструкции WAITFOR. Если приложение активируется компонентом Service Broker или запускается в виде запланированного задания, следует указать непродолжительное время ожидания, например 500 миллисекунд. Приложения, в которых применяется инструкция WAITFOR, предотвращают снижение производительности из-за непредсказуемости интервалов между сообщениями. Активируемое приложение, завершающее работу через короткий интервал времени, также не использует ресурсы при отсутствии сообщений для обработки.
Компонент Service Broker гарантирует, что в любой момент времени сообщения диалогов с общим идентификатором группы сообщений могут получать только один экземпляр приложения, проектируя приложения так, чтобы воспользоваться блокировкой группы сообщений с целью синхронизации. Если приложение сохраняет состояние, рассмотрите возможность применения идентификатора группы сообщений для идентификации состояния диалога. Обрабатывайте несколько сообщений группы сообщений в одной транзакции. Тем не менее в большинстве случаев в конкретной транзакции следует обрабатывать сообщения только одной группы сообщений. Это позволяет обрабатывать сообщения нескольким экземплярам приложения даже при сравнительно небольшом количестве групп сообщений.
Старайтесь не хранить сообщения в течение длительного времени. Вместо этого храните самые важные данные сообщений в отдельной таблице журнала — это повышает производительность. Храните сами сообщения только в случае, если приложению нужны сообщения именно в той форме, в которой они были отправлены и получены.
Завершайте диалоги при завершении задачи, так как компонент Service Broker хранит сведения о состоянии каждого активного диалога. Данные о состоянии каждого диалога имеют небольшой объем, однако производительность приложения, не завершающего диалоги, со временем может значительно снизиться.
Наконец, ограничивайте объем транзакций. Например, при передаче большого числа сообщений, относящихся к одной группе сообщений, ограничение числа сообщений, обрабатываемых в каждой транзакции, может повысить общую пропускную способность.
См. также
Другие ресурсы
Conversation Group Locks
Message Retention
Разделы руководства по мониторингу и настройке производительности