- •Аннотация
- •Cодержание
- •Введение
- •1. Теоретические основы и архитектурные принципы Web-сервисов
- •1.1. Протокол soap и стандарты ws-*
- •1.2. Архитектурный стиль rest
- •1.3. Сравнение форматов данных: xml против json
- •1.4. Сравнительная характеристика подходов
- •2. Проектирование и программная реализация системы
- •2.1. Обоснование выбора стека технологий
- •2.2. Архитектурная организация серверной части
- •2.3. Реализация уровня данных (Data Access Layer)
- •2.4. Реализация soap-сервиса
- •2.5. Реализация rest-сервиса
- •2.6. Реализация клиентского приложения и сбор метрик
- •3. Анализ производительности
- •3.1. Методика тестирования
- •3.2. Результаты тестирования
- •3.2.1. Анализ размера данных (Traffic Overhead)
- •3.2.2. Анализ вычислительной сложности (Parsing Time)
- •3.2.3. Анализ времени загрузки в плохих условиях (Slow 3g)
- •3.3. Итоговое сравнение и выводы
- •Список использованных источников
- •Приложение а Код файла student.Wsdl
- •Листинг программного кода серверной части. Index.Ts
- •Листинг программного кода серверной части. Student.Repository.Ts
- •Листинг программного кода серверной части. Student.Soap.Ts
- •Листинг программного кода серверной части. Rest.Service.Ts
- •Листинг программного кода серверной части. Soap.Service.Ts
- •Листинг программного кода серверной части. ServicePanel.Vue
3. Анализ производительности
Для оценки эффективности разработанных веб-сервисов было проведено нагрузочное тестирование с изменяемым объемом данных и в различных сетевых условиях.
3.1. Методика тестирования
Тестирование проводилось в браузере Google Chrome с использованием инструментов разработчика (DevTools). Для минимизации погрешности каждый сценарий запускался 3 раза, после чего вычислялось среднее репрезентативное значение.
Тестовые сценарии:
Сценарий «Вычислительная нагрузка» (No Throttling): Замеры на локальном сервере без ограничения сети. Цель – изолировать и измерить время работы процессора (CPU) на парсинг данных.
Сценарий «Сетевая нагрузка» (Slow 3G): Ограничение пропускной способности до 500 кбит/с и добавление задержки (latency). Цель – оценить влияние объема трафика (Overhead) на скорость загрузки.
Градация данных:
100 записей: Минимальный объем (базовая проверка).
1 000 записей: Средний объем.
5 000 записей: Высокая нагрузка.
20 000 записей: Стресс-тест системы.
3.2. Результаты тестирования
3.2.1. Анализ размера данных (Traffic Overhead)
Вне зависимости от условий сети, объем передаваемых данных остается константой. Результаты замеров представлены в таблице 3.1.
Таблица 2
Кол-во записей |
REST (JSON) |
SOAP (XML) |
Разница |
100 |
9.8 КБ |
11.5 КБ |
+17.3% |
1 000 |
98.6 КБ |
113.5 КБ |
+15.1% |
5 000 |
492.8 КБ |
566.3 КБ |
+14.9% |
20 000 |
1970.5 КБ |
2263.8 КБ |
+14.8% |
На рисунке 1 приведены результаты замеров для 20000 записей в базе данных на медленном интернете (3G)
Рисунок 1 – скриншот результата замеров для 20000 записей в базе данных на медленном интернете (3G)
Вывод: SOAP стабильно генерирует трафик на ~15% больше, чем REST. Эта разница обусловлена наличием открывающих и закрывающих тегов XML для каждого поля каждой записи. Хотя 15% кажутся небольшим значением, на больших объемах (2 МБ) это выливается в лишние 300 КБ данных, что критично для медленных сетей.
3.2.2. Анализ вычислительной сложности (Parsing Time)
Замеры времени, затраченного JavaScript-движком на преобразование ответа в объекты (без учета сети).
Таблица 3
Кол-во записей |
REST (JSON) |
SOAP (XML) |
Во сколько раз SOAP медленнее |
100 |
~0.1 мс |
~1.2 мс |
~12 раз |
1 000 |
~0.3 мс |
~8.7 мс |
~29 раз |
5 000 |
~1.1 мс |
~41.0 мс |
~37 раз |
20 000 |
~5.0 мс |
~150.0 мс |
~30 раз |
Вывод: Это наиболее показательная метрика. График роста времени парсинга для SOAP значительно круче. На 20 000 записей браузер тратит 150 мс только на разбор XML, что уже может вызывать заметные микро-фризы интерфейса (пропуск кадров анимации). REST парсится за пренебрежимо малые 5 мс. Таким образом, REST эффективнее по CPU в среднем в 30 раз.
