2010-02-06 3 views
3

Мы хотели бы кэшировать данные для некоторых выпадающих списков на клиентской машине, чтобы уменьшить передачу информации с медленным изменением. Эти данные будут использоваться на нескольких страницах в бизнес-приложении, поэтому, например, список клиентов из 5000 клиентов часто используется для поиска, создания заказа клиента или для других целей. Мы попробовали как полную загрузку данных со страницей, так и доступ к базе данных по запросу и загрузку сетки по требованию, которая возвращает только 25-50 записей. Пользователи жалуются на производительность обоих опций и хотят быстрее, поэтому мы ищем варианты того, как кэшировать данные на клиенте для повторного использования.Сведения о рассылке кэша Asp.net на клиенте

Мы видели некоторые записи о том, что онлайн-доступ к кешированию, возможно, JS-файл может быть сгенерирован сервером и локализован локально, чтобы быть источником данных для ddl, но так и не нашел, как это сделать.

Любые предложения? Или другие варианты, которые вы бы порекомендовали?

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

ответ

2

Вы можете сделать это с помощью javascript, преобразовать список в JSON и выполнить его с помощью тега сценария из кеша сервера. Я говорю JSON, потому что что-то вроде jQuery или любой другой структуры javascript может легко ее использовать.

например. в HTML/ASPX:

<script src="CustomerList.aspx?Refresh=12308798798023745" type="text/javascript"></script> 

Актуализировать быть в DateTime.Now.Ticks о последний раз он изменился на сервере. Поэтому, пока вы помещаете этот тег на каждую страницу, клиент будет извлекать его только один раз и снова, когда он фактически изменится на сервере.

Что-то вроде этого на стороне сервера:

public class Cache { 
    public static List<Customer> Customers { get; set; } 
    public static DateTime LastRefresh { get; set; } 
    public static void RefreshCustomers { 
    //Populate Customers, Customers = blah; 
    LastRefresh = DateTime.Now; 
    } 
} 

На странице:

ScriptTagwithRunAtServer.Src = "CustomerList.aspx?Refresh=" + Cache.LastRefresh.Ticks; 

В любом случае, вы предоставляете этот тег будет хорошо, просто пример. Страница CustomerList.aspx просто отобразит Cache.Customers в json-форме ... и ваша страница будет запускать небольшой javascript, чтобы сделать все возможное.

Только идея, пожалуйста, прокомментируйте, если она вас интересует, и я что-то ухожу.

+0

Это был бы мой подход, если я должен был продолжить это (и TBH, я бы попытался избежать этого и сохранить его на стороне сервера). Тем не менее, я бы также подумал о том, что сантехника в какое-то время истекает, чтобы добавить * некоторый элемент элемента управления. –

+0

@Rob - это идея '? Refresh = ####', она сообщает клиенту обновляться, когда обновляется JSON, доступный ... или вы имеете в виду истечение срока действия кеша? –

+0

Ник - это представляет интерес. Это также кэшируется на стороне клиента? Можем ли мы получить способ кэшировать список клиентов один раз на стороне клиента и повторно использовать этот кеш на нескольких страницах (не возвращаясь на сервер для списка клиентов), то есть на странице «Заказы», ​​странице поиска «Порядок» ...? – asp2go

3

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

  1. Вы смотрели на кэширование на сервере в первую очередь? Вы можете использовать OutputCache и изменять его по параметру (например, номер страницы сетки) для частичного кэширования всех просмотренных наборов данных.

  2. Что именно происходит с пользователем? Проанализируйте его с помощью firebug или fiddler и посмотрите, сколько запросов делается на сервер на страницу. Простое минимизация количества отправляемых HTTP-запросов (путем слияния и минимизации CSS и javascripts, например) будет делать чудеса для времени ответа.

  3. Что находится в вашем ViewState? Уменьшите объем данных, отправляемых туда и обратно в ViewState для более быстрой загрузки страницы.

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

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

+0

Спасибо за предложение - мы пробовали все эти моменты, и пока они помогают, проблема все еще остается. (1) yes - кэширование на сервере, где это возможно (некоторые поисковые страницы слишком динамичны для определения итераций фиксированных параметров). (2) Например, на экране, на котором вы создаете заказ клиента, есть базовая сетка заголовков и деталей. Загрузка клиентов сразу (> 5000) происходит очень медленно, но даже при загрузке 50 клиентов по запросу с использованием расширенного пейджинга Sql через пользовательский объект требуется 3-4 секунды из-за медленных сетевых подключений. – asp2go

+0

(3) Да, мы это сделали - начальный размер страницы составляет около 175 КБ, при этом большинство элементов управления просмотром на элементах управления, сообщения Ajax для извлечения клиентов - 1 КБ. На высокоскоростном сервере с высокоскоростными подключенными пользователями это работает очень хорошо и прокручивание выпадающих списков с помощью «виртуального пейджинга» даже ощущается мгновенно, но, к сожалению, со сценарием, который у нас есть, есть 3-4-секундный ответ для каждого запроса, поэтому заполнение только заголовка заказа несколькими раскрывающимися списками вызывает разочарование у пользователей. (4) Проблема не в сборе - Sql Profiler показывает 10-15 миллисекундное время. – asp2go

+0

Если мы включаем данные (только Id и Name) только для трех выпадающих списков (1000-5000 на ddl) на странице при загрузке страницы, тогда размер скачков ближе к мегабайту и отклику более 20 секунд в сети пользователя для загрузки. Конечно, после этого страница работает отлично, но мы ищем быстрый нагрузка на страницу и быстрый откат. Стоимость обновления сети/полосы пропускания в этом сценарии также чрезвычайно высока - поэтому это не может быть использовано для решения проблемы. – asp2go

Смежные вопросы