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

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

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

  1. Если соединение потеряно, весь набор результатов должен быть восстановлен и отправлен снова. Можно ли как-нибудь «возобновить», если соединение потеряно или сброшено?

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

15.08.2008 00:08:15
4 ОТВЕТА
РЕШЕНИЕ

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

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

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

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

Хранить и получать

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

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

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

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

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

3
11.04.2013 08:24:05

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

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

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

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

Так же --

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

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

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

2
15.08.2008 00:18:19

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

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

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

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

0
15.08.2008 00:31:36

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

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

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

0
15.08.2008 01:40:05