3.2.3. Анализ времени загрузки в плохих условиях (Slow 3g)

Имитация сети 500 кбит/с. В таблице приведены усредненные значения «холодного» старта (без учета кэша).

Таблица 4

Кол-во записей	REST (JSON)	SOAP (XML)	Комментарий
100	~2.0 сек	~2.3 сек	Разница минимальна
1 000	~2.0 сек	~4.4 сек	SOAP в 2.2 раза медленнее
5 000	~9.1 сек	~14.0 сек	SOAP медленнее на 5 сек
20 000	~30.4 сек	~48.8 сек	SOAP медленнее на 18 сек

Примечание: Для REST на 20 000 записей было зафиксировано значение ~30 секунд, что соответствует физической пропускной способности канала (2 МБ / 500 кбит/с ≈ 32 сек). Значения порядка 3 сек, встречавшиеся в тестах, были отброшены как результат локального кэширования браузера.

На рисунке 2 наглядно представлена разница в эффективности протоколов. Верхняя строка соответствует запросу к REST-сервису (students), нижняя – к SOAP-сервису (soap). Из данных мониторинга видно, что при передаче одинакового набора данных транспортный объем SOAP-сообщения составляет 2.3 МБ, что значительно превышает объем JSON-ответа (1.4 МБ). В условиях нестабильного соединения (Slow 3G) эта разница в объеме, суммируясь с накладными расходами на обработку XML, приводит к увеличению времени ожидания с 30 секунд до 48 секунд.

Рисунок 2 – Сравнительный анализ сетевой активности (вкладка Network) при передаче 20 000 записей в условиях ограниченной пропускной способности (Slow 3G)

Вывод:

На малых объемах (1000 записей) SOAP проигрывает в 2 раза, вероятно, из-за накладных расходов на установление соединения и более тяжелых заголовков.

На больших объемах (20 000 записей) разрыв составляет внушительные 18 секунд (30 сек против 48 сек). Это объясняется кумулятивным эффектом:

1. Лишние 300 КБ данных требуют дополнительного времени на передачу.

2. Тяжелый парсинг XML (150 мс) добавляется к общему времени.

3. Большее количество TCP-пакетов увеличивает вероятность задержек.

3.3. Итоговое сравнение и выводы

Проведенное исследование позволяет сформировать сводную сравнительную характеристику реализованных сервисов.

1. Экономия трафика: REST выигрывает с преимуществом в 15%.

2. Скорость клиента (CPU): REST демонстрирует подавляющее преимущество, работая в 30 раз быстрее. Это делает его безальтернативным выбором для мобильных веб-приложений, где заряд батареи и мощность процессора ограничены.

3. Скорость сети: В условиях плохого интернета REST позволяет получить данные значительно быстрее (на 30-50%). Пользователь SOAP-сервиса на 20 000 записях вынужден ждать почти минуту (48 с), тогда как пользователь REST – полминуты (30 с).

Таким образом, гипотеза о тяжеловесности SOAP подтвердилась практическими экспериментами. Использование XML создает двойную нагрузку: на канал связи (избыточные теги) и на процессор клиента (сложный парсинг DOM).

Характеристики ЭВМ, на которой производился тест:

• ОС: Windows 10

• Процессор: AMD Ryzen 5 4500U

• Оперативная память: 32 гб

• Среда выполнения: Node.js v20.19.1, Google Chrome v143.

ВЫВОДЫ

В ходе выполнения курсовой работы были реализованы и исследованы два типа веб-сервисов: SOAP и REST.

Практическая реализация показала, что:

1. Сложность разработки: REST значительно проще в реализации и отладке. Для SOAP требуется написание WSDL-схем и ручное формирование XML-структур (при отсутствии кодогенерации), что усложняет разработку клиентской части в браузере.

2. Производительность: REST (JSON) демонстрирует подавляющее преимущество перед SOAP (XML) в скорости обработки данных на клиенте (до 40 раз быстрее) и эффективности использования сети.

3. Область применения: SOAP остается актуальным для систем, где критически важна строгая типизация и валидация данных на уровне протокола, однако для публичных веб-API и мобильных приложений использование REST является безальтернативным стандартом де-факто из-за экономии ресурсов устройства и трафика.