#vb.net #winforms #ado.net #sqlconnection #sqlcommand
Вопрос:
Я беру на себя задачу создания панели мониторинга для устаревшего настольного приложения (LDA). Этот LDA был построен на платформе .NET Framework 2.0 и использует ADO.NET для доступа к базе данных.
Он был установлен на локальном компьютере для многих отделов и внутренних пользователей. В нем есть тысяча форм, в каждой форме есть кнопка 1-несколько, которая может управлять базой данных, вызывая хранимую процедуру SQL Server.
Проблема LDA в том, что некоторое время некоторые отделы, некоторые пользователи зависали/медленно реагировали при нажатии кнопки. Мы хотели бы записать все время выполнения хранимых процедур и поместить их все на панель мониторинга.
Мы использовали профилировщик SQL Server, но он нам не помогает, потому что не показывает, какой отдел, какой пользователь получил медленный ответ. Поэтому мы пытаемся найти решение, добавив код отслеживания в LDA (как можно меньше).
У меня есть идеал, который создает класс-оболочку SqlCommand
или SqlConnection
для измерения времени выполнения хранимой процедуры с помощью метода расширения, такого как
using(var connection = new MyCustomSqlConnection()) { ........ // currentUserObject contains all info of user and department. myCustomSqlCommand.ExecutionQuery().TrackingTime(currentUserObject); ..... }
Возможно ли это? У вас, ребята, есть образец?
Я не знаком с формой окна. Поэтому я очень признателен, если у вас есть какие-либо лучшие предложения, основанные на классе/событии формы/кнопки.
Спасибо и с наилучшими пожеланиями!
Комментарии:
1. Мое мнение по этому поводу: не создавайте никаких приложений для входа в интерфейсные приложения. Вы увеличиваете сложность и потенциальные точки сбоя, ваше ведение журнала на самом деле может вызвать раздражение из-за самих задержек, которые вы пытаетесь измерить. Если вы уверены, что задержка связана с SQL server, а не с сетью/средой, вам лучше проводить мониторинг непосредственно на этом
2. @Hursey: Я намерен создать метод TrackingTime в качестве асинхронного вызова внешней веб-службы для регистрации статистики объекта SQL-команды. Позвони и забудь. Другие логики будут обрабатываться во внешнем сервисе. Поэтому я думаю, что это не так сильно повлияет на LDA. Я хотел бы найти решение с минимальными затратами и риском.