Я реализовал поставщика SQL из Примеры расширяемости IIS UrlRewrite и, похоже, он работает хорошо, но мне интересно, как влияет на производительность вызов IIS хранимой процедуры в базе данных SQL Azure (в том же центре обработки данных) для каждого запроса к моему приложению.
Я использую Application Insights для мониторинга производительности своего приложения, но я думаю, что пользовательский поставщик перезаписи SQL не используется им, поскольку он слишком рано находится в конвейере запросов (я думаю, но я рад, что мне покажут иначе), поэтому это сложно чтобы знать, какое влияние он оказывает на каждый запрос.
Я могу отслеживать саму базу данных SQL, но это говорит только половину истории: вызовы самого SPROC возвращаются очень и очень быстро (микросекунды), но мне не хватает сетевой задержки между IIS и базой данных, которая является самой большой кусок времени будет потрачен.
Я говорю здесь только о крошечной марже, но задержка для некритичных для бизнеса баз данных Azure SQL теоретически составляет до 10 мс (но я готов поспорить, что она может быть выше в зависимости от условий сети). Для крошечных ресурсов, которые IIS обычно может возвращать менее чем за 1 мс, я действительно не хочу добавлять такую задержку, если могу.
Я знаю, что у настраиваемого поставщика SQL есть уровень кэширования, поэтому теоретически проблема не должна быть большой (например, только для первых запросов), но я просто хочу иметь возможность полностью проанализировать и определить размер проблемы, но я не могу посмотреть, как это сделать.