Возврат больших результатов через веб-сервис
Вы можете создать короткую ссылку для iTunes и Google Playstore сразу с помощью http://toSto.re .
Просто выберите имя и введите другой магазин приложений urls вы получаете ссылку, например, toSto.re/facebook, которая автоматически перенаправляет правильный URL-адрес в зависимости от пользовательского агента и даже поддерживает функцию Google Analytics для некоторых характеристик.
4 ответа
Я видел все три подхода: постраничное , сохранение и извлечение и массовое нажатие .
Я думаю, что решение вашей проблемы в некоторой степени зависит от почему ваш набор результатов такой большой и как он создается. Растут ли ваши результаты с течением времени, рассчитываются ли они все сразу, а затем передаются, хотите ли вы передать их обратно, как только они у вас появятся?
Подход с разбивкой по страницам
По моему опыту, использование метода разбиения по страницам уместно, когда клиенту необходим быстрый доступ к фрагментам результирующего набора разумного размера, аналогичным страницам в результатах поиска. Здесь следует учитывать общую болтовню вашего протокола, кэширование всего набора результатов между запросами клиентской страницы и / или время обработки, необходимое для создания страницы результатов.
Сохранение и извлечение
Сохранение и извлечение полезно, когда результаты не являются произвольным доступом, а результатом set увеличивается в размере по мере обработки запроса. Здесь необходимо учитывать сложности для клиентов, а также то, можете ли вы предоставить пользователю частичные результаты или вам нужно вычислить все результаты, прежде чем возвращать что-либо клиенту (подумайте о сортировке результатов из распределенных поисковых систем).
Massive Push
] Подход массированного пуша почти наверняка ошибочен. Даже если клиенту нужна вся информация и ее нужно поместить в монолитный набор результатов, Я бы рекомендовал воспользоваться подходом WS-ReliableMessaging (напрямую или через вашу собственную упрощенную версию) и разбить ваши результаты на части. Делая это, вы
- гарантируете, что части достигают клиента.
- может отбросить кусок, как только вы получите квитанцию от клиента
- , может уменьшить возможные проблемы с потреблением памяти из-за необходимости хранить 5 МБ XML, DOM или что-то еще в памяти (при условии, что вы не обрабатываете результаты в потоковом режиме) на стороне сервера и клиента.
Как говорили другие, не делайте ничего, пока не узнаете размер набора результатов, как он создается, и общая производительность является актуальной проблемой.
Нет никакого твердого закона против 5 Мбит в результате размера набора. Более чем 400 Мбит может быть трудно отправить.
Вы автоматически получите асинхронные обработчики (так как Вы используете .NET),
реализуйте своего рода "подкачку страниц", где набор результатов сгенерирован и сохранен на сервере, и клиент может затем загрузить блоки набора результатов в меньших суммах и повторно собрать набор в их конце
Это уже происходит для Вас - это назвало tcp/ip ;-) Перереализация, которая могла быть излишеством.
Так же-
весь набор результатов должен будет быть повторно создан и отправлен снова
Если это будет MS-SQL, например, который генерирует большую часть набора результатов - затем регенерация, то это использует в своих интересах некоторый неявный cacheing в SQL Server, и последующие поколения будут более быстрыми.
В некоторой степени можно сойти с рук не волнение по поводу этих проблем, пока они не появляются как 'реальные' проблемы - потому что платформа (платформы), которую Вы используете, заботится о большом количестве узких мест производительности для Вас.
Таким образом, это кажется, что Вы интересовались бы решением, которое добавляет 'стартовое рекордное число' и 'заключительное рекордное число' параметр к Вашему веб-методу. (или 'номер страницы' и 'результаты на страницу')
Это не должно быть слишком твердо, если запоминающее устройство является SQL-сервером (или даже mysql), поскольку они создали в поддержке нумерации строки.
Несмотря на это необходимо смочь постараться не делать любое управление сеансами на сервере, избегать любого явного кэширования набора результатов и просто полагаться на кэширование запоминающего устройства для хранения жизни простой.
Я несколько не соглашаюсь с комментарием secretGeek:
Это уже происходит для Вас - это назвало tcp/ip ;-) Перереализация, которая могла быть излишеством.
Существуют времена, когда можно хотеть сделать просто это, но действительно только с точки зрения UI. Если Вы реализуете некоторый путь к любому потоку данные клиенту (через что-то как pushlets механизм) или разделяете его на блоки в страницы, как Вы предполагаете, можно затем загрузить некоторое действительно небольшое подмножество на клиенте и затем медленно создавать UI с полным объемом данных.
Это делает для дождевика, более быстрый UI (с точки зрения пользователя), но необходимо оценить, если дополнительное усилие будет стоить..., потому что я не думаю, что это будет незначительный объем работы.