Возврат больших результатов через веб-сервис
-
08-06-2019 - |
Вопрос
В данный момент я работаю над веб-сервисом, и есть вероятность, что возвращаемые результаты могут быть довольно большими (> 5 МБ).
Совершенно верно, что этот набор данных такой большой, и веб-сервис можно назвать либо синхронным, либо асинхронным, но мне интересно, что люди думают по поводу следующего:
Если соединение будет потеряно, весь набор результатов должен быть восстановлен и отправлен снова.Есть ли способ, которым я могу сделать какое -либо «резюме», если соединение потеряно или сброшено?
Уместна ли отправка такого большого набора результатов?Было бы лучше реализовать своего рода «подкачку», при которой набор результатов генерируется и сохраняется на сервере, а клиент может затем загружать фрагменты набора результатов в меньших объемах и повторно собирать набор на их конце?
Решение
Я видел все три подхода, пейджинговый, хранить и извлекать, и массивный толчок.
Я думаю, что решение вашей проблемы в некоторой степени зависит от того, почему ваш набор результатов такой большой и как он генерируется.Растут ли ваши результаты со временем, рассчитываются ли они все сразу, а затем отправляются, хотите ли вы передать их обратно, как только они у вас появятся?
Пейджинговый подход
По моему опыту, использование разбиения на страницы целесообразно, когда клиенту необходим быстрый доступ к фрагментам результирующего набора разумного размера, аналогичным страницам в результатах поиска.Здесь учитываются общая болтливость вашего протокола, кэширование всего набора результатов между запросами клиентских страниц и/или время обработки, необходимое для создания страницы результатов.
Храните и извлекайте
Хранение и извлечение полезно, когда результаты не являются произвольным доступом и размер набора результатов увеличивается по мере обработки запроса.Здесь следует учитывать сложность для клиентов и возможность предоставить пользователю частичные результаты или вам необходимо вычислить все результаты, прежде чем возвращать что-либо клиенту (подумайте о сортировке результатов из распределенных поисковых систем).
Массивный толчок
Подход массированного продвижения почти наверняка ошибочен.Даже если клиенту нужна вся информация и ее необходимо объединить в монолитный набор результатов, я бы рекомендовал использовать подход WS-ReliableMessaging
(либо напрямую, либо через вашу собственную упрощенную версию) и разбиение результатов на части.Сделав это, вы
- гарантировать, что детали дойдут до клиента
- можете отказаться от чанка, как только получите квитанцию от клиента
- может уменьшить возможные проблемы с потреблением памяти из-за необходимости сохранять в памяти 5 МБ XML, DOM или чего-либо еще (при условии, что вы не обрабатываете результаты в потоковом режиме) на стороне сервера и клиента.
Однако, как уже говорили другие, не делайте ничего, пока не узнаете размер набора результатов, способ его генерации и общую производительность, которые являются актуальными проблемами.
Другие советы
Не существует жесткого закона, запрещающего размер 5 МБ в результате установленного размера.Более 400 Мб может быть сложно отправить.
Вы автоматически получите асинхронные обработчики (поскольку вы используете .net).
Реализуйте какую-то «пейджинг», в котором сгенерируется и хранится на сервере, и клиент может затем загрузить куски результатов в меньших количествах и повторно скомплектовать набор на своем конце
Это уже происходит с вами — это называется tcp/ip ;-) Повторная реализация этого может оказаться излишним.
Сходным образом --
Целый набор результатов должен быть восстановлен и отправлен снова
Если, например, MS-SQL генерирует большую часть набора результатов, то при его повторном создании будет использоваться некоторое неявное кэширование в SQL Server, и последующие поколения будут быстрее.
В какой-то степени вы можете не беспокоиться об этих проблемах, пока они не станут «настоящими» проблемами, потому что платформа(ы), которую вы используете, позаботится о многих узких местах производительности за вас.
Я несколько не согласен с комментарием secretGeek:
Это уже происходит с вами — это называется tcp/ip ;-) Повторная реализация этого может оказаться излишним.
Бывают случаи, когда вы можете захотеть сделать именно это, но на самом деле только с точки зрения пользовательского интерфейса.Если вы реализуете какой-либо способ либо потоковой передачи данных клиенту (с помощью чего-то вроде механизма pushlets), либо разбиваете их на страницы, как вы предлагаете, вы можете затем загрузить на клиент какое-то действительно небольшое подмножество, а затем медленно создавать пользовательский интерфейс с помощью полный объем данных.
Это делает пользовательский интерфейс более приятным и быстрым (с точки зрения пользователя), но вам нужно оценить, будут ли дополнительные усилия оправданы...потому что я не думаю, что это будет незначительный объем работы.
Похоже, вас заинтересует решение, которое добавляет в ваш веб-метод параметр «начальный номер записи» и «конечный номер записи».(или «номер страницы» и «результатов на странице»)
Это не должно быть слишком сложно, если резервным хранилищем является сервер sql (или даже mysql), поскольку в них встроена поддержка нумерации строк.
Несмотря на это, вы сможете избежать какого-либо управления сеансами на сервере, избегать явного кэширования набора результатов и просто полагаться на кэширование резервного хранилища, чтобы упростить свою жизнь.