Возврат больших результатов через веб-сервис

Question

В данный момент я работаю над веб-сервисом, и существует вероятность того, что возвращаемые результаты могут быть довольно большими (> 5 МБ).

Вполне допустимо, чтобы этот набор данных был таким большим, и веб-сервис можно назвать либо синхронизированным, либо асинхронным, но мне интересно, что думают люди о следующем:

1. Если соединение потеряно, весь набор результатов должен быть регенерируется и отправляется снова. Есть любым способом я могу сделать любой вид «возобновить», если связь потеряна или сбросить?

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

Answer 1

Я видел все три подхода: разбитый на страницы , сохраняет и извлекает и массовый пуш .

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

Пейджинговый подход

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

Сохранение и получение

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

Массивный толчок

Массивный толчок почти наверняка ошибочен. Даже если клиенту нужна вся информация и его нужно поместить в монолитный набор результатов, я бы порекомендовал воспользоваться подходом WS-ReliableMessaging (напрямую или через собственную упрощенную версию) и распределить результаты по частям. Делая это, вы

1. гарантировать, что кусочки дойдут до клиента
2. может отказаться от чанка, как только вы получите чек от клиента
3. может уменьшить возможные проблемы с потреблением памяти из-за необходимости сохранять 5 МБ XML, DOM или чего-либо еще в памяти (при условии, что вы не обрабатываете результаты потоковым способом) на стороне сервера и клиента.

Как и другие говорили, ничего не делайте, пока не узнаете размер набора результатов, то, как он генерируется, и общую производительность, чтобы быть фактическими проблемами.

Answer 2

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

Вы автоматически получите асинхронные обработчики (так как вы используете .net)

реализовать какую-то "подкачку", где набор результатов генерируется и сохраняется на сервере и клиент может тогда загрузить фрагменты набора результатов в меньшие суммы и собрать установить в их конце

Это уже происходит для вас - это называется tcp / ip ;-) Повторная реализация, которая может быть излишней.

Аналогично -

весь набор результатов должен быть восстановлено и отправлено снова

Если, например, MS-SQL генерирует большую часть набора результатов, то для его повторной генерации будет использоваться неявное кэширование в SQL Server, и последующие поколения будут выполняться быстрее.

В некоторой степени вы можете сойти с ума, не беспокоясь об этих проблемах, пока они не станут «настоящими» проблемами - потому что платформа (-ы), которую вы используете, позаботятся о многих проблемах производительности для вас. 1021 *

Answer 3

Похоже, вас заинтересует решение, которое добавляет в ваш веб-метод параметр «номер начальной записи» и «номер конечной записи». (или «номер страницы» и «результаты на страницу»)

Это не должно быть слишком сложно, если резервным хранилищем является сервер sql (или даже mysql), поскольку в них встроена поддержка нумерации строк.

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

Answer 4

Я несколько не согласен с комментарием secretGeek:

Это уже происходит для вас - это называется tcp / ip ;-) Повторная реализация, которая может быть излишней.

Бывают моменты, когда вы можете захотеть сделать именно это, но на самом деле только с точки зрения пользовательского интерфейса. Если вы реализуете какой-либо способ для потоковой передачи данных клиенту (с помощью чего-то вроде механизма pushlets), или разбиваете его на страницы, как вы предлагаете, вы можете загрузить действительно небольшое подмножество на клиент и затем медленно создать пользовательский интерфейс полный объем данных.

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