SQL (или linq to sql) работает медленнее при вызове из winforms, чем при вызове из веб-приложения?

Question

Сегодня мы столкнулись со странным поведением sql / linq:

Мы привыкли использовать веб-приложение для выполнения некоторых интенсивных действий с базой данных в нашей системе.Недавно мы перешли на интерфейс winforms по разным причинам.

Мы обнаружили, что производительность серьезно снизилась: действие, которое раньше занимало около 15 минут, теперь занимает целый час.Странно то, что Это тот же самый вызываемый метод. Метод выполняет довольно много операций чтения / записи с использованием linq2sql, и профилирование на клиентском компьютере показало, что проблемный раздел находится на самом действии SQLв методе "Сохранить".

Единственное отличие между случаями состоит в том, что в одном случае метод вызывается из кода веб-приложения (в данном случае MVC), а в другом - из формы Windows.

Одна идея, которую я мог придумать, заключается в том, что производительность SQL связана с идентификацией пользователя, обращающегося к БД, но я не смог найти поддержки для этого предположения.

Есть идеи?

Answer 1

Это очень старая проблема, но я столкнулся с вопросом только сейчас. Таким образом, для кого это может касаться в наше время, решение (и решение проблемы) было до смешного глупым. Linq2SQL был настроен на компьютерах разработчиков для постоянной записи журнала в консоль .

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

Автоматическое ведение журнала. Это была проблема.

Answer 2

Вы запускали оба теста с одной и той же машины?Если бы не аппаратные различия могли быть проблемой ... или сетью ... можно было бы быть в более высокой скорости вашей сети ... как в том же VLAN, что и сервер SQL.Попробуйте запустить клиентский код на том же сервере, на котором работало веб-приложение.

Также, если ваше приложение обновляет прогресс синхронно, приложение может долго ждать обновления дисплея ... в отличие от работы с потоком ala response.write.

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