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

Москва 2023

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

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

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

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

А.А. Жердев

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

Часть 2

Практикум

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

№ 4358

УДК 004.9 
 
Ж59

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

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

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

Рассмотрены способы оптимизации производительности серверной 
части приложения с помощью распространенных инструментов: 
многопоточность и сокеты. На примере указанных технологий 
сформулированы и решены учебные задачи. Приведен 
пример разработки REST API на языке PHP.
Пособие предназначено для студентов, обучающихся в бакалавриате по направлению 09.03.02 «Информационные системы 
и технологии».

УДК 004.9

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

ОГЛАВЛЕНИЕ

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

Практическая работа № 1. Разработка REST API 
на языке PHP ...............................................................6

Практическая работа № 2. Многопоточность 
и асинхронность ......................................................... 40

Практическая работа № 3. Работа с вебсокетами ............ 76

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

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

ВВЕДЕНИЕ

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

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

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

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

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

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

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

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

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

ПРАКТИЧЕСКАЯ РАБОТА № 1  
Разработка REST API на языке PHP

Цель работы

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

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

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

Backend и Frontend

Разделение на Backend и Frontend позволяет оптимизировать 
разработку приложения, повысить производительность, 
отказоустойчивость. Backend используется для описания бизнеслогики, в моделях данных и других операциях, происходящих 
на стороне сервера. Frontend же отвечает за пользовательский 
интерфейс. Ввод / вывод информации, взаимо действие с 
пользователем, а также посылание запросов на сервер – зоны 
ответственности фронтенда. Многие знакомые вам приложения 
и сервисы используют такое разделение. Например, сервисы 
Яндекса, VK, Telegram, а также другие сервисы и приложения.

Обычно в веб-приложениях фронтенд можно реализовывать 
при помощи HTML, CSS и JavaScript.
• HTML (HyperText Markup Language) говорит браузеру, 

каково содержание страницы, например «заголовок», «параграф», «
список», «элемент списка».
• CSS (Cascading Style Sheets) говорит браузеру, как отображать 
элементы, например «после первого параграфа отступ 
в 20 пикселей» или «весь текст в элементе body должен 
быть темно-серым и написан шрифтом Verdana».
• JavaScript говорит браузеру, как реагировать на некоторые 
взаимодействия, используя легкий язык программирования. 
Большинство сайтов на самом деле не используют 

много JavaScript, но если вы нажмете на что-то и содержимое 
страницы поменяется без белого мигания экрана, значит, 
где-то использовался JavaScript.
Бэкенд, в свою очередь, отвечает за все вычисления, происходящие 
на сервере. Для бэкенда можно использовать любые 
инструменты, доступные на сервере (который, по сути, 
является просто компьютером, настроенным для ответов на 
сообщения). Это означает, что возможно использование любого 
универсального языка программирования: Ruby, PHP, 
Python, Java, JavaScript, C++. Такой подход также означает, 
что возможно использование системы управления базами данных, 
таких как, например, MySQL, PostgreSQL, MongoDB, 
Cassandra, Redis, Memcached и др.

Взаимодействие бэкенда и фронтенда

Теперь рассмотрим, как взаимодействуют фронтенд и бэкенд друг с другом. Если рассматривать просто, то схема взаимодействия 
выглядит следующим образом:
1) фронтенд отправляет пользовательскую информацию 

в бэкенд;
2) обработка информации на стороне бэкенда;
3) информация возвращается обратно, принимая понятную 
для пользователя форму.
Остановимся на архитектуре, определяющей тип взаимодействия 
фронтенда и бэкенда.

Серверные приложения

В этом случае HTTP-запросы отправляются напрямую на 

сервер приложения, а сервер отвечает HTML-страницей.
Между получением запроса и ответом сервер обычно ищет 

по запросу информацию в базе данных и встраивает ее в шаблон (
ERB, Blade, EJS, Handlebars).
Когда страница загружена в браузере, HTML определяет, 

что будет показано, CSS – как это будет выглядеть, а JS – всякие 
особые взаимодействия.

Связь с использованием AJAX

Другой тип архитектуры использует для связи AJAX (Asynchronous JavaScript and XML). Это означает, что JavaScript, загруженный 
в браузере, отправляет HTTP-запрос (XHR, XML 
HTTP Request) изнутри страницы и (так сложилось исторически) 
получает XML-ответ. Сейчас для ответов также можно использовать 
формат JSON.
Это значит, что у вашего сервера должна быть конечная 

точка, которая отвечает на запросы JSON- или XML-кодом. 
Два примера протоколов, используемых для этого, – REST и 
SOAP.

Клиентские (одностраничные) приложения

AJAX позволяет вам загружать данные без обновления 

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

Универсальные / изоморфные приложения

Некоторые библиотеки и фреймворки, например React и 

Ember, позволяют вам исполнять приложения как на сервере, 
так и на клиенте.
В этом случае для связи фронтенда с бэкендом приложение 
использует и AJAX, и обрабатываемый на сервере HTML.

Программный интерфейс приложения (API)

API (Application programming interface, программный интерфейс 
приложения) – это набор способов и правил, по которым 
различные программы общаются между собой и обмениваются 
данными. «Ко мне можно обращаться так и так, 
я обязуюсь делать то и это».
Все эти взаимодействия происходят с помощью функций, 

классов, методов, структур, а иногда констант одной програм

мы, к которой обращаются другие. Это основной принцип работы 
API.
Допустим, вы покупаете билет в кино с помощью банковской 
карты. Во время покупки терминал обращается к API 
банка, который выпустил вашу карту, и отправляет запрос 
на оплату. А если вы заказываете такси через приложение, 
оно обращается к платежной системе тоже через API.
Программный интерфейс похож на договор между клиентом 
и продавцом. Только клиентом выступает приложение, 
которому нужны данные, а продавцом – сервер или ресурс, 
с которого мы эти данные берем. В таком договоре прописываются 
условия того, как и какие данные может получить 
клиент.
API используется:
• В языках программирования он помогает функциям 

корректно общаться друг с другом. Вызывающая функция 
должна соблюдать тип данных и последовательность параметров 
вызываемой функции.
• В операционной системе он помогает программам получать 
данные из памяти или менять настройки ОС. Поэтому, 
чтобы разрабатывать приложения под конкретную операционную 
систему, нужно знать ее API.
• В вебе сервисы общаются друг с другом через программный 
интерфейс. Если API открытый, то официальную документацию 
по работе с ним публикуют создатели сервиса-источника. 
Например, Telegram, сервисы Яндекса, Mail Ru Group.

Основные протоколы API

SOAP – это протокол, по которому веб-сервисы взаимодействуют 
друг с другом или с клиентами. Название происходит 
от сокращения Simple Object Access Protocol (простой 
протокол доступа к объектам). SOAP API – это веб-сервис, 
использующий протокол SOAP для обмена сообщениями 
между серверами и клиентами. При этом сообщения должны 
быть написаны на языке XML в соответствии со строгими 
стандартами, иначе сервер вернет ошибку.

SOAP может использоваться с протоколами SMTP, FTP, 

HTTP, HTTPS. Чаще всего – с HTTP как с наиболее универсальным: 
его поддерживают все браузеры и серверы. Корректное 
SOAP-сообщение состоит из нескольких структурных 
элементов: Envelope, Header, Body и Fault.
Envelope («конверт»). Это корневой элемент. Определяет 

XML-документ как сообщение SOAP с помощью пространства 
имен. Если в определении будет указан другой адрес, 
сервер вернет ошибку.
Header («заголовок»). Включает в себя атрибуты сообщения, 
связанные с конкретным приложением (аутентификация, 
проведение платежей и т.д.). В заголовке могут использоваться 
три атрибута, которые указывают, как принимающая 
сторона должна обрабатывать сообщение – mustUnderstand, 
actor и encodingStyle.
Значение mustUnderstand – 1 или 0 – говорит принимающему 
приложению о том, следует ли распознавать заголовок 
в обязательном или опциональном порядке. Атрибут actor 
задает конкретную конечную точку для сообщения. Атрибут 
encodingStyle устанавливает специфическую кодировку для 
элемента. По умолчанию SOAP-сообщение не имеет определенной 
кодировки.
Body («тело»). Сообщение, которое передает веб-прило
жение. Может содержать запрос к серверу или ответ от него.
Fault («ошибка»). Опциональный элемент. Передает уведомление 
об ошибках, если они возникли в ходе обработки 
сообщения. Может содержать вложенные элементы, которые 
проясняют причину возникновения ошибки.
REST API – это способ взаимодействия сайтов и вебприложений с сервером. Его также называют RESTful. REST 
(Representational State Transfer) – это способ создания API 
с помощью протокола HTTP. На русском его называют «передачей 
состояния представления».
Технологию REST API применяют везде, где пользователю 
сайта или веб-приложения нужно предоставить данные 
с сервера. Например, при нажатии иконки с видео на виде

охостинге REST API проводит операции и запускает ролик 
с сервера в браузере. В настоящее время это самый распространенный 
способ организации API.

Принципы REST API

Отделение клиента от сервера (Client-Server). Клиент – 

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

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

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

Единство интерфейса (Uniform Interface). Все данные 

должны запрашиваться через один URL-адрес стандартными 
протоколами, например HTTP. Это упрощает архитектуру 
сайта или приложения и делает взаимодействие с сервером 
понятнее.
Многоуровневость (Layered System). В RESTful сервера 

могут располагаться на разных уровнях, при этом каждый 
сервер взаимодействует только с ближайшими уровнями и 
не связан запросами с другими.
Предоставление кода по запросу (Code on Demand). Серверы 
могут отправлять клиенту код (например, скрипт для 
запуска видео). Так общий код приложения или сайта становится 
сложнее только при необходимости.