Метод ускорения работы сетевых приложений на основе превентивной загрузки данных клиенту с сервера

Размещено на http://www.allbest.ru/

Метод ускорения работы сетевых приложений на основе превентивной загрузки данных клиенту с сервера

Кравцова Н.А., Ерёменко А.В., Аверкиев С.Н.

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

Стандартные сетевые (web-) приложения работают по следующей схеме. Блок логики основной работы программы и модель данных располагаются на ЭВМ с общим доступом к ресурсам, называемой сервером. Графический пользовательский интерфейс располагается на компьютере пользователя и является по своей функциональности терминалом. Таким образом, серверная часть обеспечивает полную функциональность приложения. Клиенту же остаётся только вызывать удалённые процедуры обработки, причём, обращения к ним с точки зрения пользователя производятся как к локальным. Однако вызов удалённой процедуры не то же самое, что вызов локальной процедуры.

РЕШЕНИЕ ПРОБЛЕМЫ ЗАДЕРЖКИ ОТКЛИКА С ПОМОЩЬЮ АСИНХРОННОГО ВЗАИМОДЕЙСТВИЯ КЛИЕНТА И СЕРВЕРА

Задержка между запросом и откликом отвлекает от решаемой задачи пользователя и заставляет переключить внимание на особенности самого интерфейса. Дополнительные вычисления, связанные с передачей по сети, часто так замедляют работу, что задержка становится заметной. Для обычных приложений, предназначенных для выполнения на настольных системах, малая практичность является следствием неправильных решений, принятых при разработке. В случае сетевого соединения мы получаем тот же результат автоматически.

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

Итак, задержка при передаче по сети является основной причиной плохой интерактивности современных приложений в сети Интернет. Решение проблемы задержки отклика при сетевом взаимодействии программных блоков должно быть в создании интерфейса, независимого от сетевого взаимодействия.

В настольных приложениях, где программные блоки взаимодействуют в пределах одной ЭВМ, проблему задержек отклика решают путем организации длительных вычислений в отдельном потоке в фоновом режиме. Во время работы фонового потока пользователь может выполнять другие действия. В сетевых приложениях данный подход в чистом виде реализовать невозможно. Протокол HTTP обеспечивает связь клиента и сервера в режиме запрос-ответ, после чего связь разрывается. Таким образом, в сетевых приложениях программными средствами нельзя влиять на задержку, связанную со взаимодействием по сети, но можно минимизировать ее влияние, обращаясь к удаленным методам в асинхронном режиме.

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

Асинхронное взаимодействие означает, что связь «запрос клиента - ответ сервера» разрывается. Клиент не прекращает свою работу с приложением пока производится отсылка запросов серверу по сети и их обработка. Послав запрос серверу, клиент не обязан дожидаться ответа сервера прежде, чем пошлёт второй запрос.

Условно схему асинхронного взаимодействия можно представить следующим образом. (рис.1)

Рисунок 1 - Схема асинхронного взаимодействия клиента и сервера в web-приложении

Таким образом, данная схема позволяет посылать запросы на удалённый ресурс независимо от того, что происходит в данный момент на клиентской стороне. Этот факт позволяет применить технологию превентивной загрузки, которая успешно используется в системном программировании и организации кэш-блоков любого уровня.

ПРЕВЕНТИВНАЯ ЗАГРУЗКА ДАННЫХ КЛИЕНТУ

Организация превентивной загрузки в сетевых приложениях выглядит так. Далеко не каждый клик или наводка мыши пользователя инициирует запрос на сервер. Клиентский модуль сам определяет, выполнить ли необходимые пользователю действия силами программного модуля, загруженного пользователю, или обратиться к удаленной процедуре на сервере.

Что касается обратной стороны - стороны сервера, то тут также проявляется асинхронность. Далеко не каждый запрос к серверу являлся результатом действия пользователя. Некоторые запросы могли быть сгенерированы клиентским модулем самостоятельно.

Эффективность подобной загрузки данных напрямую зависит от степени «угадывания» тех данных, которые понадобятся пользователю. Если клиенту страница, загруженная превентивно потребуется в какой-либо из следующих моментов - мы в выигрыше, поскольку загрузили её заранее и снизили время ожидания пользователя. Если она не потребовалась, но потребовалась другая, которую мы не загрузили, мы не в выигрыше, но и не в проигрыше, поскольку одним оператором любую из ошибочно превентивно загруженных страниц можно освободить и загрузить на её место нужную. сервер сетевой приложение модуль

Несмотря на то, что данная схема превентивной загрузки данных имела опыт быть внедрённой в некоторые системы, например, в работе операционных систем при организации механизма свопа данных на жёстком диске, в работе кэш-памяти, в некоторых других программных комплексах, её эффективность не достигала такого высокого уровня, как при внедрении её в работу web-приложений. Объясняется это прежде всего тем, что режим работы процессов операционной системы, как и других процессов, исключал продолжительные периоды «бездействия системы». Эта технология внедрялась в системы с повышенной интерактивностью, где промежутки между запросами сервера настолько малы, что сделать предварительную загрузку данных незаметно для пользовательского запроса невозможно. В таких системах удачей будет только стопроцентное угадывание будущего запроса. В других случаях попытки предварительно что-либо загрузить будут увеличивать время задержек.

Однако, если речь идёт о web-приложениях, то степень «угадывания» необходимых страниц оказывается достаточно высока. На то есть несколько причин.

Во-первых, пользователь в процессе работы с узлом сети загружает ограниченный набор страниц. То есть количество потенциально загруженных страниц сокращается до количества страниц в узле.

Во-вторых, многие страницы реализованы на шаблонном принципе. То есть определённая запрошенная информация повторяется от страницы к странице. Отсюда можно сказать, что информация, запрошенная пользователем, является в большей степени предсказуемой. При переходах между страницами загружаются только переменные части страницы.

В-третьих, схема возможных переходов по страницам заранее известна, то есть мы можем сказать, какие из набора страниц узла могут быть затребованы при следующем переходе, а какие - нет.

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

При внедрении данного подхода в традиционную схему работы web-приложения на поверхность выходит недостаток подхода. А именно, увеличение объёма пересылаемой информации клиенту. Осуществляется загрузка клиенту не только запрошенных им страниц, но и неиспользуемых страниц в случае неудачи при попытке предположить требуемый узел.

Однако этот недостаток исчезает, если использовать не традиционный режим работы web-приложений, а асинхронную частичную загрузку страницы.

АЛГОРИТМ ПРЕДВАРИТЕЛЬНОЙ ЗАГРУЗКИ

После выполнения запроса пользователя проверить, нет ли запроса на загрузку следующей страницы (блока данных).

Если такой запрос имеется - выполнить его. После чего выполнить пункт 3.

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

Организовать очередь запросов на загрузку.

Послать запрос на первый информационный блок из очереди.

Приостановить алгоритм, чтобы дать возможность модулю получить и обработать ответ от сервера.

Вернуться к первому пункту.

Данный алгоритм можно представить в виде блок-схемы. (рис.2)

Рисунок 2 - Алгоритм предварительной загрузки данных с сервера в web-приложении

Однако у такого алгоритма несложно проследить характерные минусы. Поскольку мы не обладаем возможностью предвидения действий пользователя, то вероятна ситуация, когда очередная превентивная загрузка страницы (блока) будет запущена непосредственно перед тем, как пользователь осуществит переход.

ОРГАНИЗАЦИЯ ПАРАЛЛЕЛЬНЫХ АСИНХРОННЫХ ИНИЦИАЦИЙ ЗАПРОСОВ ПОЛЬЗОВАТЕЛЯ И КЛИЕНТСКОГО МОДУЛЯ

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

Рисунок 3 - Уточнённый алгоритм предварительной загрузки данных

Во втором случае следует дождаться ответа от сервера на запрос, инициированный клиентским модулем, и только после этого послать запрос, инициированный пользователем. В этом случае мы затормозим работу на время загрузки одного блока данных. И то только в случае если этот блок оказался не тем, которых в этот момент запросил пользователь. Однако поскольку вероятность невелика, как и ущерб, то издержками данной ситуации можно пренебречь.

Cледовательно, эффективнее всего при попытке пользователя послать запрос на сервер во время осуществления загрузки превентивных данных проверять совпадение двух запросов. Если пользователь запросил именно тот блок данных, ожидание загрузки которого в данный момент происходит, то следует продолжать ожидать ответа сервера. Уменьшение задержки в таком случае очевидно. В противном случае, нужно посылать новый запрос на данные, требуемые пользователем. При таком варианте ситуация аналогична работе приложения без механизма предварительной загрузки.

Представим описанный механизм на схеме (рис. 3).

Заключение

В сетевом приложении основная доля временных задержек приходится на ожидание ответа сервера. Для минимизации этого времени был предложен механизм предварительной загрузки страниц клиенту при котором выдвигается предположение о необходимости пользователю определённой страницы в будущем. Данный метод успешно применялся в системном программировании при работе настольных приложений. Однако в случае web-приложений степень эффективности возрастает в несколько раз. Основными причинами этого являются ограниченный набор потенциально загружаемых страниц, требуемых пользователю, шаблонный принцип организации страниц, известная схема переходов по страницам.

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

Литература

1. Гудман, С. Введение в разработку и анализ алгоритмов [Текст] / С. Гудман, С. Хидетниеми - М.: Мир, 1981. - 368 с.

2. Зулис, В.Я. Проектирование перспективных вариантов структур сложных технических систем [Текст] / В.Я. Зулис, Я.К. Тентерис. Перспективы развития вычислительных систем (применение идей адаптации и эволюции) / II Всесоюзный семинар. - Рига, Риж. политехн. ин-т. 1985 г. - стр. 77-80.

Размещено на Allbest.ru