Лучшая стратегия для извлечения больших динамически указанных таблиц на странице ASP.NET

Question

Ищите несколько советов о том, как оптимизировать один из наших проектов.У нас есть система ASP.NET/C#, которая извлекает данные из данных SQL2008 и представляет их в DevExpress ASPxGridView.Полученные данные могут поступать из одной из нескольких баз данных - все они немного отличаются и регулярно добавляются и удаляются.Пользователю предоставляется список действующих "компаний", а данные извлекаются из соответствующей базы данных.

В данный момент данные извлекаются с использованием стандартного SqlDataSource и динамически созданного оператора SQL SELECT.В операторе есть несколько JOIN, а также необязательные ограничения WHERE, которые снова создаются динамически в зависимости от базы данных и уровня разрешений пользователя.

Все это прекрасно работает (честно!), Кроме производительности.Когда дело доходит до некоторых баз данных, существует несколько сотен тысяч строк, и поиск и разбиение по страницам данных происходит довольно медленно (базы данных уже правильно проиндексированы).Поэтому я искал способы ускорения работы системы, и она сводится к двум вариантам: XPO или LINQ.

LINQ, кажется, является популярным выбором, но я не уверен, насколько легко будет реализовать систему с такой динамичной природой - нужно ли мне создавать «определения» для каждой базы данных, которую LINQмог получить доступ?Я также немного не уверен в динамическом создании запросов LINQ, хотя, глядя на несколько примеров, эта часть, по крайней мере, кажется выполнимой.

XPO, с другой стороны, кажется, позволяет мне создавать данные XPOИсточник на лету.Тем не менее, я не могу найти слишком много информации о том, как присоединиться к другим таблицам.

Может кто-нибудь предложить какой-либо совет, какой метод - если таковой имеется - лучше всего попробовать и вписаться в этот проект?Или динамическая модель SQL, используемая в настоящее время, принципиально отличается от LINQ и XPO, и ее лучше оставить в покое?

Answer 1

Насколько я понимаю, вы говорите о так называемом режиме сервера , когда все операции с данными выполняются на сервере БД, а не передаются на веб-сервер и обрабатываются там.В этом режиме сетка работает очень быстро с источниками данных, которые могут содержать сотни тысяч записей.Если вы хотите использовать этот режим, вы должны либо создать соответствующие классы LINQ, либо классы XPO.Если вы решите использовать серверный режим на основе LINQ , LINQServerModeDataSource предоставит событие Selecting, которое можно использовать для установки пользовательского IQueryable и KeyExpression.Я хотел бы предложить вам использовать LINQ в вашем приложении.Надеюсь, эта информация будет вам полезна.

Answer 2

Прежде чем перейти и изменить весь способ взаимодействия вашего приложения с базой данных, просмотрите следующее:

• Выполните код через профилировщик производительности (например,Профилировщик производительности Redgate), результаты часто бывают удивительными.

• Если вы строите строку SQL на лету, то используете ли вы лучшие методы .Net, такие как String.Concat ("str1", "str2") вместо "str1" + "str2".Помните, что многократные небольшие выигрыши сводятся к большим выигрышам.

• Задумывались ли вы о том, чтобы иметь сводную таблицу или базу данных, которые периодически обновляются (скажем, каждые 15 минут, возможно, вам потребуется запустить службуобновить эти данные автоматически.) так, что вы попали только в одну базу данных.Новые подключения к базам данных обходятся дорого.

• Вы смотрели на планы запросов для SQL, который вы используете.Сегодня я переместил динамически созданную строку SQL в sproc (изменился только 1 параметр) и сократил время работы на 5-10 секунд (его вызывали 100-10000 раз в зависимости от некоторых условий).

Просто предупреждение, если вы используете LINQ.Я видел некоторых разработчиков, которые решили использовать LINQ для написания более неэффективного кода, потому что они не знали, что делают (например, потянули 36 000 записей, когда им нужно было проверить 1).Об этих вещах очень легко забыть.

Просто кое-что, с чего можно начать, и, надеюсь, есть кое-что, о чем вы даже не подумали.

Приветствия,

Stu

Answer 3

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

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

Во-вторых, вы говорите, чтотаблицы правильно проиндексированы.Если это так, и вы предполагаете, что вы не загружаете 1000 страниц на страницу одновременно и получаете только подмножества за раз, тогда вы должны быть в порядке.

Но, если вы используете ExecuteQuery() только для соединения SQL, чтобы вернуть набор данных, я не вижу, как Linq или что-то еще поможет вам.Я бы сказал, что проблема явно на стороне БД.

Таким образом, чтобы решить проблему с базой данных, вам нужно профилировать различные операторы SELECT, с которыми вы работаете, изучать план запросов и определять места, где все замедляется.Возможно, вы захотите начать с использования SQL Server Profiler , но если у вас есть хороший администратор базы данных, иногда достаточно просто посмотреть план запроса (который вы можете получить из Management Studio).