My<cod/>.net
Возврат больших результатов через веб-сервис
В данный момент я работаю над веб-сервисом, и есть вероятность, что возвращаемые результаты могут быть довольно большими ( > 5 Мб).
Вполне допустимо, чтобы этот набор данных был таким большим, и веб-сервис можно назвать либо синхронизацией, либо асинхронностью, но мне интересно, что думают люди о следующем:
Если соединение потеряно, то весь результирующий набор должен быть регенерировали и отправляли снова. Есть любым способом я могу сделать все что угодно "resume" если соединение потеряно или сбросить?
Является ли отправка результирующего набора такого большого размера вообще уместной? Может быть, лучше реализовать какой-то "paging", где результирующий набор генерируется и хранится на сервере, а клиент может затем загружать куски результирующего набора в меньших количествах и повторно собирать набор в их конце?
Я видел все три подхода: пейджинг , хранение и извлечение , а также массированный толчок .
Я думаю, что решение вашей проблемы в некоторой степени зависит от того, почему ваш результирующий набор так велик и как он генерируется. Растут ли ваши результаты с течением времени, рассчитываются ли они все сразу, а затем выталкиваются, хотите ли вы передать их обратно, как только они у вас появятся?
Подход Подкачки
По моему опыту, использование метода разбиения на страницы целесообразно в тех случаях, когда клиенту требуется быстрый доступ к достаточно крупным фрагментам результирующего набора, подобным страницам в результатах поиска. Здесь рассматриваются общие характеристики вашего протокола, кэширование всего результирующего набора между запросами клиентской страницы и / или время обработки, необходимое для создания страницы результатов.
Хранить и извлекать
Хранение и извлечение полезно, когда результаты не являются произвольным доступом и результирующий набор увеличивается в размере по мере обработки запроса. Вопросы, которые следует рассмотреть здесь, - это сложность для клиентов и если вы можете предоставить пользователю частичные результаты или если вам нужно вычислить все результаты, прежде чем возвращать что-либо клиенту (подумайте о сортировке результатов из распределенных поисковых систем).
Массивный Толчок
Подход массированного толчка почти наверняка ошибочен. Даже если клиенту нужна вся информация, и ее нужно поместить в монолитный результирующий набор, я бы рекомендовал использовать подход WS-ReliableMessaging (либо напрямую, либо через вашу собственную упрощенную версию) и разбить ваши результаты на части. Делая это вы
- убедитесь, что детали дошли до клиента
- можете отказаться от куска, как только получите квитанцию от клиента
- можно уменьшить возможные проблемы с потреблением памяти от необходимости сохранять 5 Мб XML, DOM или что-то еще в памяти (при условии, что вы не обрабатываете результаты потоковым способом) на стороне сервера и клиента.
Однако, как уже говорили другие, не делайте ничего, пока не узнаете размер вашего результирующего набора, как он генерируется и общую производительность, чтобы быть актуальными проблемами.
Нет жесткого закона против 5 Мб в качестве размера результирующего набора. Более 400 Мб может быть трудно отправить .
Вы автоматически получите асинхронные обработчики (так как вы используете .net)
реализовать какой-то "paging" где результирующий набор генерируется и сохраняется на сервере и клиент может тогда загрузите фрагменты результирующего набора в меньшие количества и повторно собрать установить на свой конец
Это уже происходит для вас - это называется tcp/ip ; -) повторная реализация, которая может быть излишней.
Аналогично --
весь результирующий набор должен быть регенерировал и отправил снова
Если это MS-SQL, например, который генерирует большую часть результирующего набора, то повторная генерация будет использовать преимущества некоторого неявного кэширования на сервере SQL, и последующие поколения будут быстрее.
В какой-то степени вы можете не беспокоиться об этих проблемах, пока они не проявятся как проблемы 'real'-потому что платформа(ы), которую вы используете, заботится о многих узких местах производительности для вас.
Я несколько не согласен с комментарием secretGeek:
Это уже происходит для вас - это называется tcp / ip ; -) повторная реализация, которая может быть излишней.
Бывают моменты, когда вы можете захотеть сделать именно это, но на самом деле только с точки зрения UI. Если вы реализуете какой-то способ либо потоковой передачи данных клиенту (через что-то вроде механизма pushlets), либо разбить его на страницы, как вы предлагаете, вы можете затем загрузить некоторое действительно небольшое подмножество на клиенте, а затем медленно построить UI с полным объемом данных.
Это делает slicker более быстрым UI (с точки зрения пользователя), но вы должны оценить, будут ли дополнительные усилия стоить того... потому что я не думаю, что это будет незначительный объем работы.
Таким образом, похоже, что вам будет интересно решение, которое добавляет параметр "начальный номер записи" и "конечный номер записи" к вашему веб-методу. (или 'page number' и "результаты на странице")
Это не должно быть слишком сложно, если резервным хранилищем является сервер sql (или даже mysql), поскольку они встроены в поддержку нумерации строк.
Несмотря на это, вы должны уметь избегать любого управления сеансами на сервере, избегать любого явного кэширования результирующего набора и просто полагаться на кэширование резервного хранилища, чтобы сохранить свою жизнь простой.