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

Откуда: Санкт-Петербург
Сообщений: 345
Добрый день, коллеги.
Возник вопрос:
Есть сайт. На сайт могут коннектиться разные пользователи.
Весь сайт работает на условно одной базе (несколько баз, но на одном сервере).
Хочу профилировщиком посмотреть,, при каких действиях на сайте в какие базы идут данные.
Но тут выяснилось, что сайт работает с базой через штук 50 различных сервисов.

В рамках разных сервисов, разные пользователи сайта обращаются к базе с одного и того же пользователя (NTUserName, LoginName).
Но для каждого сервиса используется свой @@SPID.

В итоге в профилировщике нельзя нормально отфильтровать данные ни по пользователю, ни по SPID, а поток данных очень плотный - по 50 событий в секунду и больше - очень геморройно ловить нужные запросы.

Кто сталкивался с подобной проблемой - можете подсказать, как в таком случае поступать (переделать всю сервисную архитектуру вне рамок моих компетенций/возможностей, интересует именно как можно обойти проблему).
30 июл 19, 14:21    [21937889]     Ответить | Цитировать Сообщить модератору
 Re: Как нормально пользоваться профилировщиком запросов при сервис-ориентированной архитектуре  [new]
Sergey Syrovatchenko
Member

Откуда:
Сообщений: 134
Что мешает под каждый сервис свой логин сделать? И все логины включить потом в группу, чтобы права у всех можно было удобно менять.
30 июл 19, 14:31    [21937900]     Ответить | Цитировать Сообщить модератору
 Re: Как нормально пользоваться профилировщиком запросов при сервис-ориентированной архитектуре  [new]
Александр Бердышев
Member

Откуда: Санкт-Петербург
Сообщений: 345
Sergey Syrovatchenko
Что мешает под каждый сервис свой логин сделать? И все логины включить потом в группу, чтобы права у всех можно было удобно менять.

Что значит под каждый сервис свой логин?
Под 50 сервисов - 50 логинов - так это отладку через профилировщик никак не упростит.
30 июл 19, 15:52    [21937989]     Ответить | Цитировать Сообщить модератору
 Re: Как нормально пользоваться профилировщиком запросов при сервис-ориентированной архитектуре  [new]
Sergey Syrovatchenko
Member

Откуда:
Сообщений: 134
Есть такая классная штука в классе ConnectionStringBuilder - ApplicationName. Если леньки под каждый сервис заводить свой логин и иметь порядок, то ок. Задавая ApplicationName для каждого сервиса можно будет отслеживать от кого запрос.
30 июл 19, 16:25    [21938027]     Ответить | Цитировать Сообщить модератору
 Re: Как нормально пользоваться профилировщиком запросов при сервис-ориентированной архитектуре  [new]
SERG1257
Member

Откуда:
Сообщений: 2729
>поток данных очень плотный - по 50 событий в секунду и больше
Профайлер это уже не модно. XEvents ваш друг.
30 июл 19, 16:36    [21938039]     Ответить | Цитировать Сообщить модератору
 Re: Как нормально пользоваться профилировщиком запросов при сервис-ориентированной архитектуре  [new]
Александр Бердышев
Member

Откуда: Санкт-Петербург
Сообщений: 345
SERG1257
>поток данных очень плотный - по 50 событий в секунду и больше
Профайлер это уже не модно. XEvents ваш друг.

Спасибо за подсказку, не слышал раньше про такое.
Почитал - очень полезная тема!
30 июл 19, 17:47    [21938127]     Ответить | Цитировать Сообщить модератору
 Re: Как нормально пользоваться профилировщиком запросов при сервис-ориентированной архитектуре  [new]
Владислав Колосов
Member

Откуда:
Сообщений: 7762
Александр Бердышев,

Вы не правильно делаете. При таком потоке данные профилировщика необходимо сохранять в файл локально или в локальную базу, иначе завалите сервисы. Затем уже просматривать в оффлайне.
30 июл 19, 18:42    [21938178]     Ответить | Цитировать Сообщить модератору
 Re: Как нормально пользоваться профилировщиком запросов при сервис-ориентированной архитектуре  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31355
SERG1257
Профайлер это уже не модно. XEvents ваш друг.
XEvents вместо профайлера не решит проблему.
ПРроблема же в идентификации.
Как понять, какие события относятся к нажатию кнопки в проге разработчиком, если прогу мучают ещё 1000 пользователей, а никакой идентификации запроса нет?
ИМХО, нужно как то предусматривать логирование в архитектуре, в сервисах, притом в режиме с логированием можно использовать другой App Name, тогда разработчики могут просто накладывать фильтр, ведь разработчиков не так много, как пользователей. Если это вообще возможно, конечно, ведь в сервисах могут быть и асинхронные процессы.
30 июл 19, 19:24    [21938212]     Ответить | Цитировать Сообщить модератору
 Re: Как нормально пользоваться профилировщиком запросов при сервис-ориентированной архитектуре  [new]
Александр Бердышев
Member

Откуда: Санкт-Петербург
Сообщений: 345
alexeyvg
SERG1257
Профайлер это уже не модно. XEvents ваш друг.
XEvents вместо профайлера не решит проблему.
ПРроблема же в идентификации.
Как понять, какие события относятся к нажатию кнопки в проге разработчиком, если прогу мучают ещё 1000 пользователей, а никакой идентификации запроса нет?
ИМХО, нужно как то предусматривать логирование в архитектуре, в сервисах, притом в режиме с логированием можно использовать другой App Name, тогда разработчики могут просто накладывать фильтр, ведь разработчиков не так много, как пользователей. Если это вообще возможно, конечно, ведь в сервисах могут быть и асинхронные процессы.

Вы правы насчёт того, что проблему это не решило...
Думал, можно в контекст какой-нибудь произвольный дополнительный параметр передавать - но ничего подобного в XEvents нет.

Переписывать же 50 сервисов ради меня одного никто тоже не будет.
Пока думаю что делать, скорее всего придётся просто забить...
30 июл 19, 19:40    [21938223]     Ответить | Цитировать Сообщить модератору
 Re: Как нормально пользоваться профилировщиком запросов при сервис-ориентированной архитектуре  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31355
Александр Бердышев
Думал, можно в контекст какой-нибудь произвольный дополнительный параметр передавать - но ничего подобного в XEvents нет.
Так вы же ничего не можете сделать в принципе.

Сервисы делают коннекты, выполняют запросы, независимо от того, что вы там наменяли в вашем приложении.
Они же на то и сервисы, что бы быть независимыми.

Так что 100% без кореркции архитектуры/сервисов эту проблему не решить.

Просто сейчас подумайте на эту тему, а когда/если проблемой озаботятся ваши коллеги, предложите решение, и что бы оно было достаточно комплексным, удобным, а не "заткнуть дыру".
30 июл 19, 20:10    [21938248]     Ответить | Цитировать Сообщить модератору
 Re: Как нормально пользоваться профилировщиком запросов при сервис-ориентированной архитектуре  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31355
Александр Бердышев
Вы правы насчёт того, что проблему это не решило...
Думал, можно в контекст какой-нибудь произвольный дополнительный параметр передавать - но ничего подобного в XEvents нет.
Единственно, если как то косвенно (типа, прога передаёт какой нибудь GUID обрабатываемого документа, а вы фильтруете запроссы по тексту, по вхождению этого GUID)
30 июл 19, 20:12    [21938252]     Ответить | Цитировать Сообщить модератору
 Re: Как нормально пользоваться профилировщиком запросов при сервис-ориентированной архитектуре  [new]
invm
Member

Откуда: Москва
Сообщений: 9349
Александр Бердышев
В итоге в профилировщике нельзя нормально отфильтровать данные ни по пользователю, ни по SPID
Можно фильтровать по Hostname + ClientProcessID. Если в ваших сервисах Hostname не используется каким-то экзотическим образом.
30 июл 19, 21:55    [21938308]     Ответить | Цитировать Сообщить модератору
 Re: Как нормально пользоваться профилировщиком запросов при сервис-ориентированной архитектуре  [new]
Mind
Member

Откуда: Лучший город на Земле
Сообщений: 2322
alexeyvg
.
Так что 100% без кореркции архитектуры/сервисов эту проблему не решить.
Вопрос, а есть ли проблема? Пока что были озвучены только хотелки - хочу смотреть что сервисы в базе делают при действия пользователя на сайте. Практическое применение то какое?
30 июл 19, 22:06    [21938312]     Ответить | Цитировать Сообщить модератору
 Re: Как нормально пользоваться профилировщиком запросов при сервис-ориентированной архитектуре  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31355
Mind
alexeyvg
Так что 100% без кореркции архитектуры/сервисов эту проблему не решить.
Вопрос, а есть ли проблема? Пока что были озвучены только хотелки - хочу смотреть что сервисы в базе делают при действия пользователя на сайте. Практическое применение то какое?
Какое практическое применение отладки, трассировки, профайлинга?
Ну, это удобно для разработки.
И полезно для эксплуатации (для выявления каких то проблем, что бы инженер видел не окно "что то пошло не так", а всю цепочку выполнения.
invm
Можно фильтровать по Hostname + ClientProcessID. Если в ваших сервисах Hostname не используется каким-то экзотическим образом.
Это же невозможно сделать, не меняя сервисы.
Если сервис, например, сохраняет в очередь (в памяти) какие то запросы от клиентов, а потом в других потоках выполняет эти запросы, в нескольких коннектах к сиквелу, то с чего он будет передавать какой то там "Hostname + ClientProcessID"?
Нужно будет поменять сервисы, что бы они это делали. Допустим, передавали бы некий "идентификатор бизнес-запроса" насквозь, каким то образом привязывали бы его ко всем действиям, обращениям к внешним сервисам и т.д. В частности, при коннекте к сиквелу писали бы его в тот же Hostname, AppName и т.п. Или идентификатор сессии клиента.

И это ещё мы не берём случаи, когда, при обработки такой очереди, сервис не делает оптимизацию по клиентам, например, делает общий запрос на несколько запросов клиента (к примеру, если нескролько клиентов ищут что то в близких геообластях, то можно сделать общий запрос по общей геообласти; в общем, что то типа оптимизации запросов в дисковых очередях)
30 июл 19, 23:16    [21938368]     Ответить | Цитировать Сообщить модератору
 Re: Как нормально пользоваться профилировщиком запросов при сервис-ориентированной архитектуре  [new]
Владислав Колосов
Member

Откуда:
Сообщений: 7762
имо под "сервисом" надо понимать метод.
Без исходников веб-приложения не узнаешь - какой метод какие процедуры выполняет. Раз ве что можно собрать данные в отдельный файл и медитировать над старт-стопами и SPID. Но это мало что даст для понимания реализации веб-методов.
31 июл 19, 01:04    [21938439]     Ответить | Цитировать Сообщить модератору
 Re: Как нормально пользоваться профилировщиком запросов при сервис-ориентированной архитектуре  [new]
invm
Member

Откуда: Москва
Сообщений: 9349
alexeyvg
Это же невозможно сделать, не меняя сервисы.
Если сервис, например, сохраняет в очередь (в памяти) какие то запросы от клиентов, а потом в других потоках выполняет эти запросы, в нескольких коннектах к сиквелу, то с чего он будет передавать какой то там "Hostname + ClientProcessID"?
https://docs.microsoft.com/en-us/sql/relational-databases/sql-trace/sql-trace?view=sql-server-2017
ClientProcessID 9 The ID assigned by the host computer to the process where the client application is running. This data column is populated if the client process ID is provided by the client.
То же самое, что и host_process_id в sys.dm_exec_sessions.
Причем тут вами перечисленное?
31 июл 19, 10:37    [21938585]     Ответить | Цитировать Сообщить модератору
 Re: Как нормально пользоваться профилировщиком запросов при сервис-ориентированной архитектуре  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31355
invm
https://docs.microsoft.com/en-us/sql/relational-databases/sql-trace/sql-trace?view=sql-server-2017
ClientProcessID 9 The ID assigned by the host computer to the process where the client application is running. This data column is populated if the client process ID is provided by the client.
То же самое, что и host_process_id в sys.dm_exec_sessions.
Причем тут вами перечисленное?
В вашей цитате речь о ClientProcessID от сиквельного клиента, а сиквельный клиент - сервисы - топикстартеру недоступен. Ему доступен только клиент этих сервисов, то есть клиент клиента.

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

И вот задача - при клике в приложении понять, какие вызовы на сиквеле относятся к этому клику?

Вот, к примеру, мы тут на форуме постим посты, как мне оттрейсить все действия на сиквеле, которые были вызваны нажатием "Опубликовать" именно с моего компа, из моего окошка браузера? Не внося изменений в код сервера sql.ru? Какой ClientProcessID передаётся из моего браузера в коннект к сиквелу?
31 июл 19, 12:24    [21938744]     Ответить | Цитировать Сообщить модератору
 Re: Как нормально пользоваться профилировщиком запросов при сервис-ориентированной архитектуре  [new]
invm
Member

Откуда: Москва
Сообщений: 9349
alexeyvg
В вашей цитате речь о ClientProcessID от сиквельного клиента, а сиквельный клиент - сервисы - топикстартеру недоступен. Ему доступен только клиент этих сервисов, то есть клиент клиента.
ТС хочет фильтровать результаты в профайлере ничего не меняя в инфраструктуре. Я предложил вариант.
Идентификация сервиса по Host+ClientProcessID уже проблема ТС.
31 июл 19, 12:57    [21938800]     Ответить | Цитировать Сообщить модератору
 Re: Как нормально пользоваться профилировщиком запросов при сервис-ориентированной архитектуре  [new]
buser
Member

Откуда: Санкт-Петербург
Сообщений: 4537
invm
alexeyvg
В вашей цитате речь о ClientProcessID от сиквельного клиента, а сиквельный клиент - сервисы - топикстартеру недоступен. Ему доступен только клиент этих сервисов, то есть клиент клиента.
ТС хочет фильтровать результаты в профайлере ничего не меняя в инфраструктуре. Я предложил вариант.
Идентификация сервиса по Host+ClientProcessID уже проблема ТС.

Мдя...
Александр Бердышев
при каких действиях на сайте в какие базы идут данные.

Только гильотина... только логирование на бекенде... какой к лешему профайлер?!
31 июл 19, 13:03    [21938810]     Ответить | Цитировать Сообщить модератору
 Re: Как нормально пользоваться профилировщиком запросов при сервис-ориентированной архитектуре  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31355
buser
Только гильотина... только логирование на бекенде... какой к лешему профайлер?
Да, наверное, это лучше всего.
Но варианты имеются, в том числе для фильтрации в профайлере.
Так что, повторю, нужно проработать разные механизмы, к тому времени, когда начальство созреет.
31 июл 19, 13:51    [21938894]     Ответить | Цитировать Сообщить модератору
 Re: Как нормально пользоваться профилировщиком запросов при сервис-ориентированной архитектуре  [new]
SomewhereSomehow
Member

Откуда: Moscow
Сообщений: 2480
Блог
alexeyvg,
+1

Был в похожей ситуации как ТС, когда-то, работал на проекте, где была такая архитектура:
Клиент -> Application Server (SOAP Web Services) -> SQL Server.
Все заморочки с правами, пользователями, группами были реализованы на Application Server. Грубо говоря, на веб-сервисе вызывался метод CheckUser, потом методы DoSomeBusinessAction.

Все, что касается любых идентификаторов клиента DoSomeBusinessAction в соединении с SQL Server - никак не могло сказать, кто из клиентов сделал этот вызов (если только для DoSomeBusinessAction не требовалось имя пользователя). Нормально задействовать Profiler в такой истории не получится, также как xEvents, сиквелу просто неоткуда брать эти данные, если клиент их не передает, точнее передает одно и то же.

Но у меня другая задача была, чем у ТС. Мне Profiler был нужен для выявления проблем производительности, так что без разницы, кто вызывает долгий запрос, я его и так могу по длительности отловить. Но когда нужно было все-таки идентифицировать, я либо:
- Включал логирование на веб-сервере (у нас был IIS), там то ли надо было что-то установить, то ли просто включалось, уже не помню - но для разработчика - усилий ноль. Все пишется в XML файл, ты потом просто смотришь, видишь все методы, все значения параметров, время и т.д. Минус - сильно возрастает нагрузка, нужно включать краткосрочно, для отладки.
- Либо, разбирал вручную парные вызовы CheckUser и DoSomeBusinessAction. Если приложение не нагружено (у нас так и было), с определенной вероятностью, можно сказать, что два последовательных вызова относятся к одному и тому же веб-методу, который определяет бизнес-логику.

В любом случае без манипуляций на промежуточном слое между клиентом и SQL Server не обойтись.
31 июл 19, 14:54    [21938972]     Ответить | Цитировать Сообщить модератору
 Re: Как нормально пользоваться профилировщиком запросов при сервис-ориентированной архитектуре  [new]
TaPaK
Member

Откуда: Kiev
Сообщений: 6801
SomewhereSomehow,
автор
- Включал логирование на веб-сервере (у нас был IIS), там то ли надо было что-то установить, то ли просто включалось, уже не помню - но для разработчика - усилий ноль. Все пишется в XML файл, ты потом просто смотришь, видишь все методы, все значения параметров, время и т.д. Минус - сильно возрастает нагрузка, нужно включать краткосрочно, для отладки.

Да включается трассировка iis вполне в 2 клика. Главное не надолго, объёмы на нагруженных сервисах будут приличные, потом трасса вполне красиво открывается и разгребается
31 июл 19, 15:01    [21938980]     Ответить | Цитировать Сообщить модератору
 Re: Как нормально пользоваться профилировщиком запросов при сервис-ориентированной архитектуре  [new]
SomewhereSomehow
Member

Откуда: Moscow
Сообщений: 2480
Блог
TaPaK,

Ну значит примерно правильно помню, спасибо за уточнение.
31 июл 19, 15:11    [21939006]     Ответить | Цитировать Сообщить модератору
Все форумы / Microsoft SQL Server Ответить