Программные продукты и системы

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

Ситуация изменилась, когда некоторые предприятия, например «МАЗ», «Атлант», начали стремительно развиваться, создавать сервисные центры, филиалы и представительства в других странах и расширять клиентскую базу. Поддерживать связь с удаленными клиентами позволила сеть Интернет, однако из-за определенной ограниченности пропускной способности каналов связи и более высокой вероятности потерь данных увеличение времени передачи данных, а вследствие этого и замедление работы клиент-серверных приложений стало ощутимой проблемой. Кроме того, многие такие приложения не включали даже технологию сжатия (компрессии) данных, так как на момент проектирования и разработки не предусматривалось их использование в рамках более широких, чем локальная сеть предприятия, которая ограничена, как правило, зданием, несколькими корпусами или небольшой территорией.

В итоге возникли две проблемы. Во-первых, необходимы были метод и инструменты для ускорения работы клиент-серверных приложений путем снижения среднего времени ожидания клиентом ответа от сервера. Во-вторых, данный метод не должен был никоим образом затрагивать логику работы существующих клиент-серверных приложений и требовать их модификации. Другими словами, была поставлена задача разработки прозрачного для клиент-серверного приложения WAN-акселератора (Wide Area Network) (будь то программный продукт или аппаратно-програм­мный комплекс), который позволил бы сократить время ожидания ответа клиентом, особенно в нестабильных сетях или сетях с малой пропускной способностью, и при этом был бы дешевым и простым в конфигурировании [1].

Ускорение работы клиент-серверного приложения путем предупреждения отсылки дублирующих ответов посредством двойного кэширования

Перед разработкой акселератора были проведены детальные исследования особенностей работы существующих клиент-серверных приложений, используемых целевыми предприятиями, которые столкнулись с рассмотренной выше проблемой. Выяснилось, что в большинстве случаев клиент-серверные приложения были созданы с применением технологии WinForms на базе платформы .NET, а коммуникация между клиентской и серверной частями приложения базировалась либо на web-сервисах, либо на прямой отсылке и приеме HTTP-запросов (GET/POST-запросов) и HTTP-ответов с помощью методов .NET. При этом данные передавались по сети в виде XML-сериализо­ванных объектов на базе SOAP-протокола. В большинстве случаев алгоритмы компрессии и шифрования отсутствовали, хотя степень сжатия таких данных варьировалась от 40 до 80 %, поэтому прежде всего было предложено применить в рамках акселератора современные алгоритмы компрессии и шифрования. Но в ходе исследований была замечена еще одна существенная деталь. В приложениях в среднем 50 % ответов сервера клиенту дублировались в течение 3 часов, то есть клиент многократно запрашивал данные от сервера, которые не претерпели никаких изменений в течение 3 часов.

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

Разработанный акселератор, как и клиент-сер­верное приложение, состоит из двух частей: клиентской (далее акселератор-клиент) и серверной (далее акселератор-сервер), между которыми устанавливается TCP-соединение (рис. 1). Он представляет собой прокси-сервер, через который осуществляется передача данных между клиентской и серверной частями приложения. И акселератор-клиент, и акселератор-сервер имеют свой собственный кэш в оперативной памяти либо на жестком диске компьютера-клиента и компьютера-сервера соответственно, то есть кэширование информации происходит как на стороне клиента, так и на стороне сервера.

При перехвате HTTP-запроса от клиента акселератором-клиентом для него формируются постоянный уникальный ключ, который создается путем хеширования строки URI запроса и, если это POST-запрос, его тела, а также временный уникальный ключ, сгенерированный случайным образом. Под временным ключом копия запроса помещается в кэш акселератора-клиента, а сам запрос направляется дальше акселератору-серверу. Акселератор-сервер получает запрос, помещает его копию под временным ключом, который в общем случае не совпадает с аналогичным ключом на клиенте, в свой кэш, вычисляет постоянный ключ, который будет совпадать с аналогичным ключом на клиенте, и направляет запрос web-сервису либо процессу-слушателю, находящемуся на стороне сервера. Web-сервис либо процесс-слушатель генерирует ответ, который приходит сначала акселератору-серверу. Последний на базе тела ответа вычисляет хеш-код, затем помещает этот код и копию ответа в кэш, связывая его с соответствующим кэшированным запросом, присваивает паре запрос-ответ постоянный ключ (временный ключ удаляется) и отсылает ответ акселератору-клиенту, который осуществляет аналогичную операцию, направляя затем ответ клиенту. Таким образом, каждый запрос и ответ на него кэшируются дважды: на клиенте и на сервере.

В случае перехвата акселератором-клиентом нового запроса последний вычисляет его хеш-код по указанному выше правилу и осуществляет поиск этого запроса по постоянному ключу в своем кэше. Если пара запрос-ответ с идентичным хеш-кодом (идентичным постоянным ключом) найдена в кэше, то акселератор-клиент посылает данный хеш-код акселератору-серверу. Тот, получив хеш-код запроса, ищет соответствующую пару запрос-ответ в своем кэше. Если такая пара имеется, то акселератор-сервер отсылает назад хеш-код ответа. Акселератор-клиент получает хеш-код ответа и сверяет с аналогичным кодом у себя в кэше. Если коды идентичны, значит, ответ не изменился на сервере, поэтому акселератор-клиент возвращает ответ конечному клиенту из собственного кэша, не затрачивая время на отсылку запроса серверу и ожидание ответа на него. При этом акселератор-сервер сразу же после отсылки хеш-кода ответа посылает запрос, который находится в его собственном кэше, web-сервису либо процессу-слуша­телю, чтобы обновить соответствующий ответ. Другими словами, акселератор-сервер асинхронно обновляет собственный кэш с тем, чтобы данные в нем были как можно актуальнее. Клиенту же будет казаться, что ответ пришел почти мгновенно, так как размер хеш-кода весьма мал (32 байта) и обмен хеш-кодами акселератора-клиента и ак- селератора-сервера занимает очень короткое время.

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

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

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

Эксперименты и обсуждение их результатов

Для тестирования и подтверждения эффективности разработанного акселератора были проведены эксперименты с использованием запросов и ответов, схожих по своей структуре с теми, что используются в работе клиент-серверных приложений целевых предприятий. Эксперименты были разделены на две группы: проводимые с использованием хорошо сжимаемых данных (степень сжатия свыше 90 %) и проводимые с использованием трудносжимаемых данных (степень сжатия менее 10 %).

Поскольку клиент-серверные приложения целевых предприятий работают под управлением операционных систем семейства Windows, для разработки акселератора использовалась платформа .NET на базе стандартных библиотек .NET Framework 3.5 Service Pack 1. При проведении экспериментов акселератор-клиент и акселератор-сервер работали на разных компьютерах в пре- делах одной локальной сети. На стороне акселе- ратора-сервера была установлена операционная система Windows Server 2008 R2, на стороне акселератора-клиента – Windows 7 Ultimate.

Компьютеры, использовавшиеся для прове- дения экспериментов, располагались на малом расстоянии друг от друга, а сама сеть обладала высокой пропускной способностью и помехозащищенностью, поэтому было принято решение использовать дополнительный компьютер. Он должен был стать посредником при передаче сигнала от сервера клиенту и наоборот, и с помощью специального программного средства WANem (Wild Area Network Emulator) имитировалась сеть с различной пропускной способностью и помехоустойчивостью (рис. 2) [2].

Размер запроса для экспериментов первой группы варьировался от 200 Кбайт до 1,5 Мбайта, а ответа – от 8 Мбайт до 12 Мбайт. Такие размеры идентичны размерам несжатого запроса и ответа клиент-серверных приложений исследуемых предприятий.

Размер запроса для экспериментов второй группы варьировался от 200 до 600 Кбайт, а ответа – от 800 Кбайт до 1,2 Мбайта. Такие размеры идентичны размерам сжатого запроса и ответа клиент-серверных приложений исследуемых предприятий.

Также в обоих случаях варьировалась пропускная способность сети в диапазоне от 512 Кбит/с до 4 Мбит/с (а именно 512 Кбит/с, 1 Мбит/с, 2 Мбит/с, 4 Мбит/с), так как сети с таким диапазоном пропускной способности наиболее часто используются на территории Беларуси.

Поскольку основной задачей разработанного акселератора является ускорение работы клиент-серверного приложения независимо от пропускной способности и состояния сети, все эксперименты проводились как на стабильной, так и на нестабильной сети, где могут происходить потери, искажение и дублирование пакетов. Для неста­бильной сети были взяты следующие параметры: задержка передачи пакетов – 250 мс, доля потерянных пакетов – 5 %, доля дублирующихся пакетов – 7 %, доля поврежденных пакетов – 10 %. Такие величины были выбраны потому, что потеря всего 5–10 % пакетов в сети может привести к значительному снижению скорости передачи данных по протоколу TCP и тем самым сделать работу клиент-серверного приложения довольно медленной, если вообще возможной [3, 4].

На рисунке 3а показан график влияния двойного кэширования и компрессии на среднее время ожидания клиентом ответа при передаче данных по стабильной сети.

Как видно из рисунка 3а, среднее время передачи несжатых данных без кэширования является самым большим и варьируется от 24 с до 4 с в зависимости от пропускной способности сети. Интересно отметить, что избирательная компрессия трудносжимаемых данных без участия кэширования не снизила, а в некоторых случаях даже увеличила среднее время передачи, что связано с затратами времени на сам процесс сжатия. Тот небольшой выигрыш во времени передачи сжатых данных нивелируется временем их сжатия. В данном случае более значимым является влияние двойного кэширования запросов/ответов. Очевидно, что, чем выше частота повторяемости идентичных запросов/ответов, тем выше эффективность работы акселератора. Так, при пропускной способности сети в 512 Кбит/с и частоте повторяемости идентичных запросов/ответов в 20 % среднее время ожидания ответа клиентом, то есть время, прошедшее с момента отсылки первого байта запроса до момента приема последнего байта ответа, составляет 20 с. При частоте повторяемости идентичных запросов/ответов в 80 % оно становится равным 9 с. Таким образом, при применении акселератора для передачи трудносжимаемых данных по стабильной сети среднее время ожидания ответа клиентом снижается на 17–79 % в зависимости от пропускной способности сети и частоты повторяемости идентичных запросов/от­ветов. Следует еще раз отметить, что среднее время ожидания ответа клиентом снижается вследствие не роста скорости передачи, а того, что часть запросов/ответов просто не передается по сети, так как актуальный ответ извлекается из кэша акселератора-клиента и возвращается практически мгновенно в клиентское приложение.

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

Следует обратить внимание на степень изогнутости кривых на графике (рис. 3б). Она значительно меньше, чем в предыдущем случае, то есть рост пропускной способности в данном случае ведет к незначительному снижению среднего времени передачи запросов/ответов. Это связано с особенностями протокола TCP, в рамках которого используется специальный алгоритм «предотвращения перегрузки» (Congestion Avoidance) [5]. Этот алгоритм резко снижает скорость передачи вне зависимости от пропускной способности канала, пока пакеты не перестанут теряться, а затем начинает медленно повышать ее до тех пор, пока снова не начнутся потери.

Из рисунка 3б видно, что среднее время ожидания ответа клиентом при использовании акселератора в нестабильной сети снижается на 14–80 % в зависимости от пропускной способности сети и частоты повторяемости идентичных запросов/от­ветов.

Эффективен акселератор и при передаче хорошо сжимаемых данных (степень сжатия более 80 %) как в стабильной, так и в нестабильной сети (рис. 3в и 3г).

Как видно из рисунка 3в, акселератор позволяет снизить среднее время ожидания ответа клиентом на 86–98 % в стабильной сети в зависимости от пропускной способности и частоты повторяемости идентичных запросов/ответов. В нестабильной сети (рис. 3г) среднее время ожидания ответа клиентом может быть снижено на 98 %.

Проведенные эксперименты затронули два крайних случая: большое количество редко повторяющихся трудносжимаемых запросов/ответов и большое количество часто повторяющихся хорошо сжимаемых запросов/ответов. В обоих случаях акселератор позволил сократить среднее время ожидания ответа клиентом и ускорить его работу. Однако следует отметить, что эффективность работы акселератора зависит от того, насколько хорошо сжимаемые и часто повторяющиеся запросы/ответы используются в целевых клиент-серверных приложениях. При использовании акселератора среднее время ожидания ответа клиентом может быть снижено на 14–98 % (см. табл.).

Процент снижения среднего времени ожидания ответа клиентом при использовании акселератора

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

Литература

1.     Rose M. WAN accelerator. SearchEnterpriseWAN. URL: http://searchenterprisewan.techtarget.com/definition/WAN-accele­rator (дата обращения: 16.01.2013).

2.     Nambiar M. WANem: The Wide Ares Network emulator. Performance Engineering Research Centre, Mumbai, 2009. URL: http://wanem.sourceforge.net/ (дата обращения: 16.01.2013).

3.     Kurose J.F., Ross W.R. Computer Networking: A Top-Down Approach. NY: Addison-Wesley, 2009, 864 p.

4.     Камер Д.Э. Сети TCP/IP: Принципы, протоколы и структура. М.: Вильямс, 2003. Т. 1. 851 с.

5.     Jacobson V., Karels M.J. Congestion Avoidance and Control. Proc. SIGCOMM’88. Stanford, CA: Stanford ACM, 1988.

References

1.     Rose M. WAN accelerator. SearchEnterpriseWAN. Available at: http://searchenterprisewan.techtarget.com/definition/WAN-accelerator (accessed 16 January 2013).

2.     Nambiar M. WANem: The Wide Ares Network emulator. Performance Engineering Research Centre, Mumbai, 2009. Available at: http://wanem.sourceforge.net/ (accessed 16 January 2013).

3.     Kurose J.F., Ross W.R. Computer Networking: A Top-Down Approach. NY, Addison-Wesley Publ., 2009, 864 p.

4.     Comer D.E. Internetworking with TCP/IP. 4th ed., Prentice Hall Publ., vol. 1, 2000, 750 с. (in Russ.).

5.     Jacobson V., Karels M.J. Congestion Avoidance and Control. Proc. SIGCOMM’88. Stanford, CA, Stanford ACM Publ., 1988.