Какие параметры влияют на производительность приложений? Часть 2. Полоса пропускания и использование канала связи
Очень часто, общаясь с ИТ-специалистами, в медленной работе корпоративных приложений обвиняют сетевой департамент или узкие каналы связи. Самое простое решение всех проблем — больше пропускной способности (шире канал) и меньше левых приложений в канале (меньше конкурентов за полосу) и тогда все будет летать. Конечно, надо обращать внимание и на чистоту каналов связи и их использование, но это не единственные параметры. Самым простым решением для оценки состояния каналов являются Flow технологии и корреляция данных между производительностью ключевого приложения и данных с NetFlow (jFlow, Sflow и т. д.).
Полоса пропускания канала связи
В сетях передачи данных, задержки — это жизненный факт. Понимая их природу, можно уменьшить отрицательный эффект, повысив тем самым качество связи. Сетевые задержки определены стандартами ITU и должны укладываться в определенные пределы:
Диапазон в миллисекундах |
Описание |
---|---|
0-150 |
Приемлемо для большинства пользовательских приложений. |
150-400 |
Допустимо при условии, что администраторы осведомлены о времени передачи и его влиянии на качество передачи в пользовательских приложениях. |
Более 400 |
Неприемлемо для общих целей планирования сетей. Однако признается, что в некоторых исключительных случаях этот предел может превышаться. |
Последовательный принцип передачи пакетов по каналу связи вносит задержки. Задержка при передаче информации от одного пользователя другому состоят из нескольких составляющих и их можно разделить на два больших класса — фиксированные и переменные.
К переменным задержкам относятся в основном задержка в очередях на каждом из узлов сети: маршрутизатор, коммутатор, сетевой адаптер. К фиксированным – задержка пакетирования, последовательная задержка, задержка кодека (для видео или аудио). Средой передачи может служить медная пара, волоконно-оптический кабель или эфир. При этом величина задержки зависит от тактовой частоты и, в гораздо меньшей степени, от скорости света в среде передачи.
В документации Cisco есть вот такая таблица, которая позволяет оценить последовательную задержку в зависимости от длины пакетов и ширины канала связи:
Размер кадра (байты) |
Скорость передачи по каналу (Кбит/с) |
||||||||||
19,2 |
56 |
64 |
128 |
256 |
384 |
512 |
768 |
1024 |
1544 |
2048 |
|
38 |
15,83 |
5,43 |
4,75 |
2,38 |
1,19 |
0,79 |
0,59 |
0,40 |
0,30 |
0,20 |
0,15 |
48 |
20,00 |
6,86 |
6,00 |
3,00 |
1,50 |
1,00 |
0,75 |
0,50 |
0,38 |
0,25 |
0,19 |
64 |
26,67 |
9,14 |
8,00 |
4,00 |
2,00 |
1,33 |
1,00 |
0,67 |
0,50 |
0,33 |
0,25 |
128 |
53,33 |
18,29 |
16,00 |
8,00 |
4,00 |
2,67 |
2,00 |
1,33 |
1,00 |
0,66 |
0,50 |
256 |
106,67 |
36,57 |
32,00 |
16,00 |
8,00 |
5,33 |
4,00 |
2,67 |
2,00 |
1,33 |
1,00 |
512 |
213,33 |
73,14 |
64,00 |
32,00 |
16,00 |
10,67 |
8,00 |
5,33 |
4,00 |
2,65 |
2,00 |
1024 |
426,67 |
149,29 |
128,00 |
64,00 |
32,00 |
21,33 |
16,00 |
10,67 |
8,00 |
5,31 |
4,00 |
1500 |
625,00 |
214,29 |
187,50 |
93,75 |
46,88 |
31,25 |
23,44 |
15,63 |
11,72 |
7,77 |
5,86 |
2048 |
853,33 |
292,57 |
256,00 |
128,00 |
64,00 |
42,67 |
32,00 |
21,33 |
16,00 |
10,61 |
8,00 |
Для передачи кадра длиной 1518 байт (максимальная длина для Ethernet) по каналу 64-кбит/сек последовательная задержка достигает 185 мс. Если по тому же каналу передавать пакеты длиной 64 байт, задержка составит всего 8 мс, т. е. чем короче пакет, тем быстрее он достигнет приемной стороны. Поэтому для передачи голоса используются короткие UDP пакеты, которые позволяют минимизировать величину задержки, а разработчики оборудования для передачи данных, напротив, стремятся к увеличению длины кадров для снижения объема служебного трафика. Для расчёта последовательной задержки можно воспользоваться формулой:
Последовательная задержка = ((кол-во байт для отправки или получения) x (8 бит))/ (самую медленную скорость в канале)
Например, последовательная задержка для отправки 100 Кбайт и получения 1 Мбайт по каналу 2 Мбит/сек составит:
Передача: (100,000 * 8) / 2,048,000 = 390 мсек
Прием: (1,024,000 *8) / 2,048,000 = 4000 мсек
Конечно, последовательная задержка это один из компонентов и на каждый из потоков будет дополнительно оказывать влияние задержка в каналах связи, джиттер и т.д. Данная формула покажет идеальную картину, когда за канал связи не борются другие пользователи или приложения. Это можно увидеть на диаграмме, которая показывает реальную скорость канала связи при передаче 200 Кбайтного файла по протоколу FTP и каналу 10 Мбит/сек.
Мы видим, что скорость в процессе передачи не постоянна. Так как сеть – среда разделяемая, то пакеты по мере передачи по сети попадают в очереди, теряются, активируется алгоритм контроля доступа к среде, который мешает одному пользователю захватить весь канал связи. Все это оказывает влияние на скорость передачи и как следствие на скорость работы приложения.
Как увеличить скорость работы приложений, не изменяя ширину полосы пропускания канала связи?
Естественно, самый простой выход – увеличить ширину канала связи, но иногда это не возможно или стоит очень дорого для корпоративных клиентов. В таком случае логично уменьшить объем данных, передаваемых в канале связи. Уменьшить объем можно несколькими способами. Сжатие данных, использование тонких клиентов, кеширование, использование решений для оптимизации трафика – это позволяет иногда добиться сокращения трафика от 2 до 5 раз (разные приложения ужимаются по-разному).
Также можно, понять структуру трафика и как реально используется канал связи с помощью Flow технологий и далее путем приоритезации трафика сократить возможные потери пакетов и рост очередей в активном оборудовании.
См. также:
- Какие параметры влияют на производительность приложений? Часть 1. TCP Window Size
- Перехват паролей с помощью Wireshark
- SaaS сервисы: плюсы и минусы
Авторизуйтесь для этого