Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
 SQL Broker: как лучше отправлять сообщения?  [new]
Winnipuh
Member [заблокирован]

Откуда: Київ
Сообщений: 10428
В триггере отправляется сообщение, чтобы затем в процедуре активации обработать измененные объекты с указанными идентификаторами.

Приблизительно так:

SET @message = N'<PUMP_SERVICE_REQUEST_MSG><msg  id="'+CAST(NEWID() AS NVARCHAR(48))+'"/>'
	
SELECT @message=@message + N'<node id="'+CAST(node_id AS nvarchar(48))+N' operation="100"/>' 
FROM INSERTED

SET @message=@message+'</PUMP_SERVICE_REQUEST_MSG>'
SET @message_xml=CAST(@message AS XML)

BEGIN DIALOG @dialog_handle
	FROM SERVICE Pump
	TO SERVICE 'PUMP_SERVICE'
	ON CONTRACT [PUMP_SERVICE_CONTRACT]
	WITH ENCRYPTION = OFF;
	SEND ON CONVERSATION @dialog_handle	MESSAGE TYPE PUMP_SERVICE_REQUEST_MSG(@message_xml) ;
	END CONVERSATION @dialog_handle;


Но при большом количестве изменяемых записей получается одно сообщение, которое далее в процедуре обрабатывается

begin tran
цикл по идентификаторам
обработка всех ид
commit tran

1. Как лучше с точки зрения производитеьности организовать обработку?
Может резать в триггере и отправлять не одно сообщение с 1000 идентификаторов, а 100 сообщений по 10?

2. Как отправлять в триггере: каждое сообщение в своем диалоге или в одном диалоге все сообщения?
22 окт 13, 13:53    [15014583]     Ответить | Цитировать Сообщить модератору
 Re: SQL Broker: как лучше отправлять сообщения?  [new]
Ennor Tiegael
Member

Откуда:
Сообщений: 3274
Winnipuh,

1. Лучше избавиться от "цикл по идентификаторам" - неужели нельзя одним запросом все обработать?
2. Одноразовые диалоги очень невыгодные, лучше иметь пул диалогов, которой можно будет при желании периодически рециклить. Реально они могут годами работать без проблем.
22 окт 13, 15:12    [15015227]     Ответить | Цитировать Сообщить модератору
 Re: SQL Broker: как лучше отправлять сообщения?  [new]
Winnipuh
Member [заблокирован]

Откуда: Київ
Сообщений: 10428
Ennor Tiegael
Winnipuh,

1. Лучше избавиться от "цикл по идентификаторам" - неужели нельзя одним запросом все обработать?
2. Одноразовые диалоги очень невыгодные, лучше иметь пул диалогов, которой можно будет при желании периодически рециклить. Реально они могут годами работать без проблем.


1. вы правы, но нельзя, там мутная история, нужно каждую запись обрабатывать.
2. вот в том и вопрос...
22 окт 13, 15:18    [15015276]     Ответить | Цитировать Сообщить модератору
 Re: SQL Broker: как лучше отправлять сообщения?  [new]
Ennor Tiegael
Member

Откуда:
Сообщений: 3274
Winnipuh,

Если обработка идет полностью независимо и вам нужно уменьшить отклик, то режьте на куски и обрабатывайте очередь в 10 / 20 / сколько выдержит потоков. Но при этом убедитесь, что эти куски уйдут в разные диалоги, иначе в процедуре активации все обратно сериализуется.
22 окт 13, 15:24    [15015330]     Ответить | Цитировать Сообщить модератору
 Re: SQL Broker: как лучше отправлять сообщения?  [new]
Winnipuh
Member [заблокирован]

Откуда: Київ
Сообщений: 10428
Ennor Tiegael
Winnipuh,

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


т.е. например в триггере вижу, что изменены 100 записей.
Я создаю 5 сообщений (по 20 идов) и отправляю их в разные диалоги, и на другом конце активирую скажем 3 экземпляра процедуры активации?
22 окт 13, 15:29    [15015384]     Ответить | Цитировать Сообщить модератору
 Re: SQL Broker: как лучше отправлять сообщения?  [new]
Ennor Tiegael
Member

Откуда:
Сообщений: 3274
Winnipuh,

Типа того. Только следите за дэдлоками - все системы, какие я видел, были построены так, что толком распараллелить не получалось. Если вставка / обновление идет в одни и те же таблицы, параллелизм может сделать только хуже.
22 окт 13, 15:38    [15015470]     Ответить | Цитировать Сообщить модератору
 Re: SQL Broker: как лучше отправлять сообщения?  [new]
Winnipuh
Member [заблокирован]

Откуда: Київ
Сообщений: 10428
Ennor Tiegael
Winnipuh,

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


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

Когда процедура его получает она открывает транзакцию и на большом апдейте практически получается почти такая же блокировка, только не в самом триггере, а через какое-то время в процедуре.
В процедуре надо бы наверное попробовать сделать транзакции покороче.
22 окт 13, 15:49    [15015554]     Ответить | Цитировать Сообщить модератору
 Re: SQL Broker: как лучше отправлять сообщения?  [new]
Winnipuh
Member [заблокирован]

Откуда: Київ
Сообщений: 10428
Почитал решение, предложенное Русану, где SPID использует свой диалог, а потом нашел еще одно: там все отправители используют один диалог, и не закрывают его.
У меня тоже односторонняя отправка. Попробую с одним на всех.
22 окт 13, 17:08    [15016344]     Ответить | Цитировать Сообщить модератору
 Re: SQL Broker: как лучше отправлять сообщения?  [new]
Winnipuh
Member [заблокирован]

Откуда: Київ
Сообщений: 10428
Winnipuh
Почитал решение, предложенное Русану, где SPID использует свой диалог, а потом нашел еще одно: там все отправители используют один диалог, и не закрывают его.
У меня тоже односторонняя отправка. Попробую с одним на всех.


по поводу не закрывают - погорячился.

Он там хитро делает:

автор
If no handle exists I create a new conversation and store the value in my settings table. If my CAST(RAND()*100 AS INT) returns 0 I send a message using the MT_ConversationSwitch message type on the existing conversation which will trigger logic in my receiving procedure telling it to end the conversation. After I end the conversation I create the new conversation and store the value.
22 окт 13, 17:23    [15016440]     Ответить | Цитировать Сообщить модератору
 Re: SQL Broker: как лучше отправлять сообщения?  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6723
/facapalm jpg

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

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

Как работать с диалогом тоже можно играться как нужно для задачи.
Если это тупая очередь и всё в перемешку - то и нет смысла создавать диалог каждый раз. Один раз его создал и навечно.
Если диалог имеет сложную логику и связывается с другими сервисами (очередями) или завязан на чём либо (некий логический объект), то да - нужно создавать.

На то он и SB что можно определить как нужно для конкретной задачи.
Нет никакого одного общего решения/подхода.
Более того можно даже не пользоваться менеджером очередей, а сразу задать 100500 обработчиков, которые будут жадно гонятся за сообщениями.
SB - это не один сервис это целая среда.
Это не говоря об приоритетах и т.п.
23 окт 13, 17:16    [15022255]     Ответить | Цитировать Сообщить модератору
 Re: SQL Broker: как лучше отправлять сообщения?  [new]
Winnipuh
Member [заблокирован]

Откуда: Київ
Сообщений: 10428
Mnior
/facapalm jpg

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

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

Как работать с диалогом тоже можно играться как нужно для задачи.
Если это тупая очередь и всё в перемешку - то и нет смысла создавать диалог каждый раз. Один раз его создал и навечно.
Если диалог имеет сложную логику и связывается с другими сервисами (очередями) или завязан на чём либо (некий логический объект), то да - нужно создавать.

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



да, в моем случае - тупая односторонняя очередь.
и я пытаюсь не возвращать ядовитые сообщения обратно в очередь, чтобы ее не заклинило.
23 окт 13, 17:34    [15022341]     Ответить | Цитировать Сообщить модератору
 Re: SQL Broker: как лучше отправлять сообщения?  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6723
Winnipuh
да, в моем случае - тупая односторонняя очередь.
Ну вы знаете что делать.
Winnipuh
и я пытаюсь не возвращать ядовитые сообщения обратно в очередь, чтобы ее не заклинило.
Волков бояться в лес не ходить.

Надо просто правильно обрабатывать, а вообще предотвращать такое в корне.

Просто при ошибках надо не валится, а обработать сообщение - кинуть в другое место, к примеру, или вернуть другое сообщение.

Если вы читаете без транзакции - то вообще ахтунг, или вы не боитесь потерять сообщения?
С таким подходом SB вообще становится наполовину бесполезным. Можно Job-ами запилить, проще выйдет.
23 окт 13, 18:11    [15022526]     Ответить | Цитировать Сообщить модератору
 Re: SQL Broker: как лучше отправлять сообщения?  [new]
Winnipuh
Member [заблокирован]

Откуда: Київ
Сообщений: 10428
Mnior
Winnipuh
да, в моем случае - тупая односторонняя очередь.
Ну вы знаете что делать.
Winnipuh
и я пытаюсь не возвращать ядовитые сообщения обратно в очередь, чтобы ее не заклинило.
Волков бояться в лес не ходить.

Надо просто правильно обрабатывать, а вообще предотвращать такое в корне.

Просто при ошибках надо не валится, а обработать сообщение - кинуть в другое место, к примеру, или вернуть другое сообщение.

Если вы читаете без транзакции - то вообще ахтунг, или вы не боитесь потерять сообщения?
С таким подходом SB вообще становится наполовину бесполезным. Можно Job-ами запилить, проще выйдет.


Я их не теряю, пишу в отдельную таблицу, но это редкие случаи.
Не, jobы не заменят, их придется пускать наобум с каким-то интервалом, а сообщения в очередь идут неравномерно и.тд.
Кроме всего, в экспрессе и LocalDB нету агента, а брокер есть.
23 окт 13, 18:29    [15022610]     Ответить | Цитировать Сообщить модератору
 Re: SQL Broker: как лучше отправлять сообщения?  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6723
Winnipuh
Я их не теряю, пишу в отдельную таблицу, но это редкие случаи.
Ну дело не в случае, а в коде/подходе.
Winnipuh
Не, jobы не заменят, их придется пускать наобум с каким-то интервалом, а сообщения в очередь идут неравномерно и.тд.
Ничего не надо, запускается N запросов в вечном цикле. Ну не суть, это оффтоп.
Winnipuh
Кроме всего, в экспрессе и LocalDB нету агента, а брокер есть.
Ну Job-ы я тут погорячился. Можно обычный WinService - на коленке за 5 минут настрогать - не суть.
Суть что преимущества почти все сливаются и начинается огород, который можно и не делать.

Ок.
23 окт 13, 22:02    [15023268]     Ответить | Цитировать Сообщить модератору
Все форумы / Microsoft SQL Server Ответить