Не знал, куда написать, но решил, что это более подходит в раздел .NET.
В SqlServer, начиная с 2005, нам дали возможность загружать сборки платформы .net
Решил ранее использовавшиеся вызовы extended stored procedure перевести в эти сборки. На время перехода предполагается следующая конфигурация:SQL-хранимая процедура, дергающая сборку-"обвязку" на C#, которая в свою очередь путем dllimport использует методы unmanaged-кода на C++. И столкнулся с достаточно долгим переключением контекстов. Решил немножко изучить вопрос и написал несколько процедур. Выводы такие:
Без параметров — время переключения контекста SQL-CLR составило 40 мкс. Два параметра- 44,3 Десять параметров — 66,3 Двадцать параметров — 75,3 Двадцать параметров, из них 18 — output, то есть мы их инициализируем в CLR и при выводе конвертим обратно — 78,3 Если инициализировать строки не StringBuilder-ом, а пустой строкой, то получаем отсутствие разницы в последних двух случаях, то есть оба по 75.3.
То есть фактически мы получаем приблизительно линейную зависимость длительности переключения от количества параметров. Грустно.
Далее, в версию с 20-ю параметрами, из которых 18-out, был встроен вызов unmanaged-библиотеки, которая выполняла запись в лог и печатала там время выполнения своей операции. Получили 113 мкс при времени выполнения самой процедуры на C++ равном 8 мкс. Итого, на переключение контекста CLR- unmanaged C мы потратили еще 30 мкс.
Есть ли идеи по поводу "как ускорить переключение"?
Заранее спасибо.
Здравствуйте, DNTester, Вы писали:
DNT>Решил ранее использовавшиеся вызовы extended stored procedure перевести в эти сборки. На время перехода предполагается следующая конфигурация:SQL-хранимая процедура, дергающая сборку-"обвязку" на C#, которая в свою очередь путем dllimport использует методы unmanaged-кода на C++.
Зря, имхо. Вы получили двойной интероп и все шансы убить весь инстанс на пустом месте.
DNT>И столкнулся с достаточно долгим переключением контекстов. Решил немножко изучить вопрос и написал несколько процедур.
А как меряли?
DNT>Есть ли идеи по поводу "как ускорить переключение"?
Подозреваю, что никак
Здравствуйте, Sinix, Вы писали:
S>Здравствуйте, DNTester, Вы писали:
S>Зря, имхо. Вы получили двойной интероп и все шансы убить весь инстанс на пустом месте.
Да нет, не зря. Функциональность очень велика и приходится пользоваться подобными "прокладками". А вот extended stored procedures на MS SQL выполняются ооочень долго.
DNT>>И столкнулся с достаточно долгим переключением контекстов. Решил немножко изучить вопрос и написал несколько процедур. S>А как меряли?
Цикл из 1000 последовательных вызовов, ибо дискретность таймера.
DNT>>Есть ли идеи по поводу "как ускорить переключение"? S>Подозреваю, что никак
Здравствуйте, Jolly Roger, Вы писали:
JR>А SuppressUnmanagedCodeSecurityAttribute пробовали? здесь
Так у ТС вроде проблема в том, что сам вызов CLR-кода тормозит.
Здравствуйте, Sinix, Вы писали:
S>Так у ТС вроде проблема в том, что сам вызов CLR-кода тормозит.
Ну вроде и переход managed -> unmanaged вклад делает:
Получили 113 мкс при времени выполнения самой процедуры на C++ равном 8 мкс. Итого, на переключение контекста CLR- unmanaged C мы потратили еще 30 мкс.
Здравствуйте, DNTester, Вы писали:
DNT>Решил ранее использовавшиеся вызовы extended stored procedure перевести в эти сборки. На время перехода предполагается следующая конфигурация:SQL-хранимая процедура, дергающая сборку-"обвязку" на C#, которая в свою очередь путем dllimport использует методы unmanaged-кода на C++. И столкнулся с достаточно долгим переключением контекстов. Решил немножко изучить вопрос и написал несколько процедур.
Уберите интероп-вызовы и померяйте стоимость переключения MSSQL/CLR, что бы узнать, где же узко — в MSSQL/CLR или в CLR/Interop. Потом уже можно будет подумать о том, что и _где_ оптимиздить.
Help will always be given at Hogwarts to those who ask for it.
Здравствуйте, _FRED_, Вы писали:
_FR>Здравствуйте, DNTester, Вы писали:
DNT>>Решил ранее использовавшиеся вызовы extended stored procedure перевести в эти сборки. На время перехода предполагается следующая конфигурация:SQL-хранимая процедура, дергающая сборку-"обвязку" на C#, которая в свою очередь путем dllimport использует методы unmanaged-кода на C++. И столкнулся с достаточно долгим переключением контекстов. Решил немножко изучить вопрос и написал несколько процедур.
_FR>Уберите интероп-вызовы и померяйте стоимость переключения MSSQL/CLR, что бы узнать, где же узко — в MSSQL/CLR или в CLR/Interop. Потом уже можно будет подумать о том, что и _где_ оптимиздить.
Так я вроде как сверху указывал стоимость переключения между SQL-CLR и между CLR-Unmanaged. У меня получилось, что SQL-CLR ну очень узко, CLR-Unmanaged — жирновато, но еще терпимо.
Здравствуйте, Аноним, Вы писали:
А>Здравствуйте, DNTester, Вы писали:
DNT>>Есть ли идеи по поводу "как ускорить переключение"? DNT>>Заранее спасибо.
А>Оформить в бухгалтерии покупку проца за четверть Вашего оклада. Результаты измерений отпишите.
Не думаю, что поможет.
Тестирование проводилось на сервере с 16-ю логическими ядрами на 2,93 ГГц и 25 Гб RAM.
Здравствуйте, DNTester, Вы писали:
DNT>Здравствуйте, Аноним, Вы писали:
А>>Здравствуйте, DNTester, Вы писали:
DNT>>>Есть ли идеи по поводу "как ускорить переключение"? DNT>>>Заранее спасибо.
А>>Оформить в бухгалтерии покупку проца за четверть Вашего оклада. Результаты измерений отпишите.
DNT>Не думаю, что поможет. DNT>Тестирование проводилось на сервере с 16-ю логическими ядрами на 2,93 ГГц и 25 Гб RAM.
Тогда надо проект завести на след. квартал «Апгрейд сервера», провести 5 совещаний с чаепитиями, назначить тендер, снова все довольны и кому-то PROFIT Чо Вы собой-то дыры затыкаете, нехай система сама за себя платит.
Здравствуйте, Jolly Roger, Вы писали:
JR>Здравствуйте, Sinix, Вы писали:
S>>Так у ТС вроде проблема в том, что сам вызов CLR-кода тормозит.
JR>Ну вроде и переход managed -> unmanaged вклад делает:
JR>
JR>Получили 113 мкс при времени выполнения самой процедуры на C++ равном 8 мкс. Итого, на переключение контекста CLR- unmanaged C мы потратили еще 30 мкс.
JR>Может быть хоть здесь удастся сэкономить
К сожалению, экономии не было.
10000 вызовов процедуры без параметра и без вызова unmanaged кода — 344 млс, то же количество вызовов с исполнением unmanaged кода — 720 млс, при суммарном времени работы unmanaged кода =70 млс. Те же 30 мкс на одно переключение.
"Нормальные герои всегда идут в обход!"
