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

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, и последующие поколения будут быстрее.

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

Answer 3

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

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

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

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

Answer 4

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

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

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