Оптимизация клиент-серверных приложений . Часть 1

Москва 2023

МИНИСТЕРСТВО НАУКИ И ВЫСШЕГО ОБРАЗОВАНИЯ РФ

Университет науки и технологий МИСИС

ИНСТИТУТ ИНФОРМАЦИОННЫХ ТЕХНОЛОГИЙ И КОМПЬЮТЕРНЫХ НАУК

Кафедра инфокоммуникационных технологий

А.А. Жердев

ОПТИМИЗАЦИЯ КЛИЕНТСЕРВЕРНЫХ ПРИЛОЖЕНИЙ

Часть 1

Практикум

Рекомендовано редакционно-издательским  
советом университета

№ 4356

УДК 004.9 
 
Ж59

Р е ц е н з е н т 
канд. техн. наук, доц. В.В. Стучилин

Жердев, Алексей Александрович.
Ж59  
Оптимизация клиент-серверных приложений : Ч. 1 : 

практикум / А.А. Жердев. – Москва : Издательский 
Дом НИТУ МИСИС, 2023. – 85 с.

Рассмотрены основные способы определения производительности 
серверной части приложения с помощью специализированного 
программного обеспечения Apache JMeter. Приведены рекомендации 
по анализу протокола клиент-серверного приложения 
через средства разработки стандартных браузеров (на примере 
Google Chrome). Представлены примеры использования менеджера 
очередей RabbitMQ.
Пособие предназначено для студентов, обучающихся в бакалавриате по направлению 09.03.02 «Информационные системы 
и технологии».

УДК 004.9

 Жердев А.А., 2023
 НИТУ МИСИС, 2023

ОГЛАВЛЕНИЕ

Введение ......................................................................4

Практическая работа № 1. Знакомство с платформой 
Apache JMeter. Нагрузочное тестирование простого  
веб-приложения............................................................6

Практическая работа № 2. Нагрузочное тестирование 
приложения со сложной бизнес-логикой ........................ 30

Практическая работа № 3. Работа с менеджерами  
очередей на примере RabbitMQ и приложения на PHP ..... 53

Заключение ............................................................... 83

Библиографический список .......................................... 84

ВВЕДЕНИЕ

Клиент-серверные приложения составляют абсолютное 

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

СУБД, а также сервером приложения, на котором выполняется 
реализованная разработчиками программа. Клиентской 
частью может выступать браузер, desktop-приложение, мобильное 
приложение, а также аналогичное ПО, предназначенное 
для формирования запросов и последующей отправки 
их на сторону сервера.
В зависимости от характера задач, количества пользователей 
и архитектуры ПО клиент-серверный обмен может быть 
как постоянным (даже в режиме реального времени), так и достаточно 
редким явлением. Правильно рассчитать его интенсивность, 
выбрать подходящие инструменты и технологии, 
разработать масштабируемую архитектуру – все это сложные инженерные 
задачи, которые являются крайне востребованными 
на современном рынке разработки программного обеспечения.
Архитектура крупных проектов редко сразу бывает идеальной. 
Ее оптимизация является постоянным спутником 
процесса разработки программного обеспечения. На ранних 
этапах развития, как правило, необходимо обеспечить скорейшую 
доставку новых версий с востребованным функционалом 
клиентам. Очень часто на этих этапах из-за скорости 
страдает архитектура, и в долгосрочной перспективе это 
приводит к тому, что система после определенного предела 
просто перестает справляться с нагрузкой.

Независимо от того, на каком этапе жизненного цикла 

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

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

Первая часть посвящена нагрузочному тестированию и 

организации очередей из поступающих запросов, а также 
эффективным способам их обработки.
Во второй части рассматриваются механизмы асинхронной 
обработки запросов, многопоточность, сокеты, а также 
приведена реализация REST API на языке PHP.
Для выполнения работ используется открытое программное 
обеспечение, распространяемое по лицензии GPU или аналогичным. 
Ссылки на программное обеспечение приведены по 
ходу выполнения практических работ.

ПРАКТИЧЕСКАЯ РАБОТА № 1  
Знакомство с платформой Apache JMeter. 
Нагрузочное тестирование простого вебприложения

Цель работы

Разобраться с видами тестирования производительности, 

освоить методику проведения нагрузочных тестов с помощью 
Apache JMeter.

Теоретический минимум

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

аналогичная. Рост количества пользователей программных 
продуктов приводит к увеличению доходности прямо или 
косвенно (через рекламу), поэтому важно обеспечить работоспособность 
приложения при заданных бизнесом объемах. 
Для того чтобы это сделать, необходимо определить производительность 
программного продукта, что в свою очередь является 
сложной исследовательской задачей.
Здесь все дело в том, что работоспособность приложения 

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

Основные понятия

Тестирование производительности (Performance Testing) – подвид тестирования, при котором осуществляется 
сбор метрик с системы в то время, когда она находится под 
нагрузкой. Основные метрики: время отклика системы, количество 
выполняемых операций в единицу времени, но могут 
быть и другие. Нагрузка может создаваться и реальными 
пользователями, но чаще всего используются виртуальные, 
которые имитируются специализированным программным 
обеспечением (Яндекс.Танк, Apache JMeter, Grinder).
Во время нагрузочного тестирования мы проверяем производительность 
всего программно-аппаратного комплекса, поэтому 
на результат измерений будет влиять не только то, как 
написана программа, но и производительность используемого 
оборудования, СУБД, каналы передачи информации, доступность 
сторонних сервисов, которые может использовать проверяемое 
приложение для своей работы и т.п.
Виртуальный пользователь (Virtual User) – программный 
процесс, циклически выполняющий моделируемые операции.

Итерация (Iteration) – это один повтор выполняемой в 

цикле операции.
Интенсивность выполнения операции (Operation Intensity) – частота выполнения операции в единицу времени, 
в тестовом скрипте задается интервалом времени между итерациями.

Нагрузка (Loading) – совокупное выполнение операций 

на общем ресурсе (входов/с, хитов/с).
Производительность (Performance) – количество выполняемых 
операций за период времени (N операций за M часов).
Профиль нагрузки (Performance Profile) – это набор операций 
с заданными интенсивностями, полученный на основе 
сбора статистических данных либо определенный путем анализа 
требований к тестируемой системе.
Основными целями нагрузочного тестирования являются:

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

разные виды тестов производительности и нагрузки.
Если интересует исследование производительности приложения, 
а именно времени отклика для операций на разных 
нагрузках в довольно широких диапазонах, включая стрессовые 
нагрузки, то это все-таки тестирование производительности (
Performance Testing).
Если целью является понимание, насколько приложение 

устойчиво в режиме длительного использования (исключение 
утечек памяти, переполнения базы данных, некорректных конфигурационных 
настроек и т.д.), то проводится долгий нагрузочный 
тест – это тестирование стабильности (Stability Test ing). 
При этом анализ времени отклика может иметь место, но не 
быть первым приоритетом, главное, чтобы система «не упала».
Стресс-тестирование (Stress Testing) имеет своей целью 

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

Этапы проведения нагрузочного тестирования

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

1. Анализ требований и сбор информации о тестируемой 

системе.
2. Конфигурация тестового стенда для нагрузочного тестирования.

3. Разработка модели нагрузки.
4. Выбор инструмента для нагрузочного тестирования.
5. Создание и отладка тестовых скриптов.
6. Проведение тестирования.
7. Анализ результатов.
8. Подготовка, отправка и публикация отчета по проведенному 
нагрузочному тестированию
Ключевым является этап разработки модели нагрузки, 
который в свою очередь состоит из нескольких шагов.
1. Определение критичных операций.
Для этого необходимо определить следующее:
• список тестируемых операций;
• интенсивность выполнения операций;
• зависимость изменения интенсивности выполнения операций 
от времени.
В список тестируемых задач должны войти операции, 

критичные с точки зрения бизнеса, а также с технической 
точки зрения.
Критичными с точки зрения бизнеса являются операции, 

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

ее влияние на бизнес-процесс и работоспособность системы. 

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

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

взаимодействия между ними;
• выделить критические с точки зрения предполагаемого 

тестирования операции. В качестве таковых могут быть выбраны:

 – 
операции с «тяжелыми» запросами к базе данных, процессы 
генерации отчетов;

 – операции, выполняемые большим количеством пользователей 
или с высокой интенсивностью;

 – операции, критичные с точки зрения бизнеса и к тому 

же удовлетворяющие условиям двух верхних пунктов.
Опрос бизнес-пользователей или совместное исследование 
с разработчиками и администраторами системы может 
значительно облегчить задачу. Если приложение находится в 
эксплуатации, то можно провести мониторинг загрузки компонентов 
аппаратных серверов (процессора, память, диски) 
и проанализировать системные журналы веб-серверов (снять 
stats pack, если в качестве сервера базы данных, например, 
используется Oracle). Системные журналы могут показать 
пики высокой активности пользователей в течение дня и дать  
количественное оценки того, сколько транзакций (хитов) 
выполняется в единицу времени. Согласно закону Паретто 
или принципу 20/80, 20 % операций приложения генериру

ют 80 % нагрузки в системе, поэтому нужно стараться выбрать 
для моделирования именно эти 20 % операций.
3. Определение профиля нагрузки.
Ключевым моментом в модели нагрузки являются выбранные 
для тестирования операции или профиль нагрузки. 
Естественно, выполняться эти операции в тесте должны одновременно. 
Профилей нагрузки для приложения может быть 
несколько, и это оправдано. Ведь бизнес-пользователи могут 
выполнять разные наборы операций в разное время. Например, 
начало операционного дня и конец дня, начало месяца 
(квартала) и, соответственно, завершение могут отличаться. 
Таким образом, получаем различные наборы операций приложения, 
выполняющиеся одновременно и, соответственно, 
создающие различную нагрузку. Кстати, меняться могут 
не только сами операции, но и их интенсивности. В первом 
приближении моделью нагрузки является набор профилей 
нагрузки, где каждый профиль отличается от другого или набором 
операций, или интенсивностями выполнения этих операций.

Пример профиля нагрузки, в который входит 4 операции, 

значение n может быть различным для каждой операции.
Профиль нагрузки:
• Операция_1 – интенсивность выполнения n раз/ед. времени.
• 
Операция_2 – интенсивность выполнения n раз/ед. времени.
• 
Операция_3 – интенсивность выполнения n раз/ед. времени.
• 
Операция_4 – интенсивность выполнения n раз/ед. времени.

Пример 1 – подготовка интернет-магазина к «черной» пятнице. 
Для этого одновременно должны выполняться следующие 
операции1.
• Регистрация пользователя – 1 раз/с.

1 В реальности профили получаются в результате анализа и сопоставления 
с бизнес-требованиями заказчика.