Наименее понятный, но самый важный фактор производительности приложения – задержка.

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

Задержка как критический для бизнеса фактор

Производительность сети измеряется двумя совершенно независимыми параметрами: пропускной способностью (измеряется в мегабайтах в секунду) и задержкой приема-передачи (измеряется в миллисекундах). Приложения с быстрым откликом повышают производительность. Поскольку пропускная способность сети улучшается в глобальном масштабе, сегодня пользователи очень чувствительны даже к небольшим задержкам. Ярким примером является Amazon, который обнаружил, что каждые 100 миллисекунд (0,1 секунды) увеличения времени загрузки его веб-сайта уменьшали их общий объем продаж на один процент.

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

Проблема задержки усугубляется «болтливыми» прикладными протоколами или наивными программами, которые были разработаны без учета задержки.

Реальный пример

Рассмотрим простой незамысловатый скрипт, удаляющий папку. Скрипт рекурсивно удаляет все файлы в папке, а затем удаляет саму папку. Удаление файла — очень быстрое упражнение, около одной миллисекунды (1 мс).

Теперь предположим, что у нас есть папка с 10 000 файлов.

Сценарий, работающий на локальном файловом сервере, будет выполняться довольно быстро, удаляя 10 000 файлов за 10 секунд.

Но сценарий не работал бы так же хорошо, если бы он выполнялся на файловом сервере, расположенном в удаленном месте, с задержкой в ​​оба конца 80 мс (типичная задержка для распределенных организаций в США, достигающих от побережья до морской берег).

Теперь операция занимает 1 мс, но помимо этого есть еще 80 мс задержки туда и обратно. Следовательно, тот же 10-секундный процесс удаления займет… 13,5 минут!

Это в 81 раз медленнее. Говорим о чудовищном убийце производительности.

Решения для задержки

Что может сделать организация, чтобы преодолеть влияние задержки на этот сценарий удаления? Одним из решений может быть распараллеливание сценария, чтобы он одновременно удалял несколько файлов. Вместо одного потока мы могли бы использовать 10 потоков, что привело бы к увеличению производительности в 10 раз и уменьшению общего времени, затрачиваемого на выполнение, до 1,3 минуты. Все еще не здорово.

Лучшим подходом было бы отправить на сервер 10 000 имен файлов, не дожидаясь ответа на каждое из них. Такой подход, часто называемый «конвейерной обработкой», «асинхронной обработкой» или «массовыми операциями», сократит время выполнения до чуть более 10 секунд. , практически исключая эффект задержки.

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

Метод кэширования

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

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

(У кэширования есть свои проблемы, связанные с разными подходами к когерентности кэша, но это тема для другой статьи.)

Задержка, близость и скорость света

В отличие от пропускной способности сетевых каналов, которая быстро растет, не ожидается, что задержка значительно уменьшится в обозримом будущем, поскольку она регулируется законами физики. Обычно скорость света в оптоволоконном кабеле составляет примерно 200 000 км в секунду. Иными словами, сигналу потребуется 5 мс, чтобы пройти 1000 км по оптоволокну.

Таким образом, задержка между Сиднеем и Нью-Йорком, находящимся на расстоянии 16 000 км, никогда не может быть меньше 80 миллисекунд. И на практике это, вероятно, будет намного длиннее, потому что волокно, вероятно, будет проходить по более длинному маршруту, и могут быть дополнительные задержки из-за различного сетевого оборудования на пути.

В действительности наблюдаемая задержка для соединения Сидней-Нью-Йорк составляет чуть более 200 мс.

Вот некоторые часто наблюдаемые задержки при обмене данными в Интернете:

Задержка никуда не исчезнет; по крайней мере, до тех пор, пока мы не добьемся значительных прорывов в квантовой физике.

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

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