Производительность WCF

Question

В нашей базе данных есть таблица, которая содержит около 250000 строк (около 3 ГБ).Возможно ли технически просмотреть данные в этой таблице в приложении silverlight, которое запрашивает эти данные с помощью WCF?Потенциально я вижу проблемы с максимальным размером буфера и ошибками тайм-аута.Возможно, нам понадобятся все данные для визуализации.

Пожалуйста, помогите мне, если есть практическое решение этой проблемы.

Answer 1

Перенос 3 ГБ на клиент не будет работать.

для целей визуализации.

Лучше подготовить визуализацию на стороне сервера.Это будет достаточно медленно.

Answer 2

Обычно в такой ситуации, если вам нужно просматривать отдельные записи, вы должны использовать стратегию подкачки.Таким образом, ваш вызов в WCF был бы предназначен для записей на одну страницу, и вы отобразили бы эти записи, а пользователь нажал бы кнопку «следующий / предыдущий» или что-то подобное.

Что касается визуализации, вам следует посмотреть, чтобы выполнить некоторыепреобразование / уменьшение на сервере в виде 2,5 миллионов записей похоже на отображение одной точки данных на пиксель на экране.

Answer 3

Прежде всего, посмотрите здесь .

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

Итак, давайте предположим, что через несколько минут / часов вы получили данные по проводам, где вы их храните? Ваше приложение Silverlight, если оно работает внутри браузера, не может увеличиться до 3 ГБ (даже на 64-битной машине), и даже оно может, это не имеет никакого смысла. Тем более, что объем данных при преобразовании в объекты займет гораздо больше места.

Вот что я бы сделал:

• Получите от сервера снимки / просмотры полезных данных, например, предоставление сводки, кубы OLAP, ...
• Для каждой записи укажите минимально необходимые данные.
• Если вам нужна подробная информация о каждой записи, сделайте это в отдельном звонке

Answer 4

Ну, я полагаю, что вы не собираетесь показывать 2,5 миллиона строк в одном и том же списке.

Если вы разрабатываете хорошую разбивку на страницы данных, и способ, которым вы запрашиваете данные, является оптимальным, я не вижу проблемы с WCF.

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

Предложения:

• Используйте OR / M. NHibernate будет вашим лучшим выбором, так как он имеет множество способов настройки производительности, а подкачка страниц упрощается благодаря поддержке LINQ через API QueryOver в NHibernate 3.0. Этот продукт имеет очень интересную схему кэширования, и он позволит вашему приложению эффективно визуализировать вашу базу данных длиной 2,5 миллиона строк.

• Заниматься кэшированием. NHibernate может помочь вам в этой области, но подумайте об этом, и, в зависимости от технологии клиента (Web, Windows ...), вы найдете хорошие варианты для кэширования представлений (например, ASP.NET для кэширования вывода).

• Подумайте, как вы собираетесь сериализовать объекты в WCF: SOAP или JSON? Возможно, вас заинтересует JSON, потому что сериализованные объекты достаточно малы, чтобы сохранить трафик в сети.

Если у вас есть вопросы, просто закомментируйте!

Answer 5

Хорошо, после того, как многие пользователи говорят о том, что вы там делаете технически - какой смысл, если кто-то, не задумываясь, думал, что вы там находитесь?

• 2,5 миллиона строк не имеют смысла в сетке.Нуль.Отображение 80 строк на странице (широкий sdcreen, наклоненный на 90 градусов), что составляет 31250 страниц данных.Вы даже не можете писать на определенной странице.Игнорирование времени загрузки - даже если (!) Вы загружаете это и т. Д., Просто не имеет смысла иметь это количество в сетке.Отфильтруйте его, затем загрузите то, что вам нужно, по страницам.Но ключ здесь заключается в том, чтобы заставить пользователя фильтровать ДО того, чтобы даже думать о сетке.И как только вы их сделаете, давайте не будем забывать о производительности сетки.

• Чтобы показать вам, насколько это плохо.Для получения сетки.Если вы назначаете ОДИН ПИКСЕЛ или каждый элемент данных, вы берете 1,33 экрана 1024 * 768 пикселей для отображения данных.Это один пиксель на элемент.

Итак, в конце дня, даже если (если это невозможно) справиться с этой работой, вы получите бессмысленный /неиспользуемое приложение.