Стратегии масштабирования для приложений ASP.NET - Уравнение производительности
ОГЛАВЛЕНИЕ
Уравнение производительности
В сентябре 2006 года Питер Севчик (Peter Sevcik) и Ребекка Ветцель (Rebecca Wetzel) из компании NetForecast опубликовали документ, именуемый "Field Guide to Application Delivery Systems" («Полевое руководство по системам доставки приложений»). Основное внимание в документе было уделено улучшению производительности приложений в глобальных сетях (wide area network – WAN), и в нем было приведено уравнение с рис. 1. Это уравнение рассматривает производительность глобальных сетей, но с несколькими мелкими изменениями его можно использовать и для измерения производительности веб-приложений. Измененное уравнение показано на рис. 2, а его элементы объяснены на рис. 3.
Рис. 1 The Original Performance Equation
Рис. 2 The Web Version of the Performance Equation
Рис. 3 Элементы уравнения производительности
| Переменная | Определение |
|---|---|
| R | Время ответа. Общее время с запроса страницы пользователем (обычно переходом по ссылке и т.п.) до полной визуализации страницы на его компьютере. Обычно измеряется в секундах. |
| Объем полезных данных | Общее число байтов, отправленных обозревателю, включая разметку и все ресурсы (такие как файлы CSS, JS и изображений). |
| Пропускная способность | Скорость передачи данных обозревателю и от него. Может быть асимметрична и представлять несколько скоростей, если данная страница создается из нескольких источников. Обычно усредняется для создания единого выражения пропускной способности в байтах в секунду. |
| AppTurns | Число файлов ресурсов, требуемых страницей. Они включают файлы CSS, JS, изображений и любые другие файлы, извлекаемые обозревателем в процессе визуализации страницы. Уравнение учитывает страницу HTML отдельно, добавляя время приема-передачи (round-trip time – RTT) перед выражением AppTurns. |
| RTT | Время, необходимое для приема и передачи данных, вне зависимости от числа переданных байтов. Каждый запрос тратит минимум одно RTT для самой страницы. Обычно измеряется в миллисекундах. |
| Одновременные запросы | Число одновременных запросов файлов ресурсов, которые выполнит обозреватель. По умолчанию Internet Explorer выполняет два одновременных запроса. Данный параметр может быть изменен, но это делается редко. |
| Cs | Время вычислений на сервере. Время, уходящее у кода на запуск, извлечение данных из базы данных и составление ответа, отправляемого обозревателю. Измеряется в миллисекундах. |
| Cc | Время вычислений на клиенте. Время, уходящее у обозревателя на визуализацию HTML на экране, исполнение JavaScript, применение правил CSS, итд. |
Теперь, когда у нас есть формула, задача заключается в том, чтобы замерить каждый элемент. С конечным значением, временем ответа, это сделать достаточно легко – имеется ряд средств, способных засечь, сколько именно времени занимает весь процесс
Объем полезных данных можно измерить с помощью различных средств (отличным вариантом является websiteoptimization.com/services/analyze), точно так же, как и пропускную способность (см. speedtest.net) и время приема-передачи (используя программу Ping). Средства вроде websiteoptimization.com/services/analyze также сообщат размер HTML, CSS, JavaScript, изображений и прочих частей веб-страницы. Число одновременных запросов по сути являются постоянной (для Internet Explorer® по умолчанию используется 2).
В результате остаются только Cs и Cc (времена вычислений на сервере и клиенте), измерение которых требует некоторых дополнительных усилий от разработчика. Написание кода на странице ASP.NET, отмечающей точную секунду, когда начинается исполнение страницы, и вычитающей это время из текущего времени при завершении исполнения, является сравнительно простой задачей. Это же верно и для клиента – небольшой кусок кода на JavaScript может быть исполнен прямо наверху страницы HTML, чтобы отметить время и затем вычесть время на момент запуска события OnLoad при завершении страницы.
Все эти элементы можно внести в программный код, если требуется создать для веб-узла режим отладки, использующий уравнение производительности. Имеется убедительная причина так и сделать: постоянное выполнение элементов уравнения производительности на обозревателе позволяет легко обнаружить, в чем состоят проблемы производительности.
Для примера, предположим, что имеется приложение ASP.NET, пользователи которого находятся на другом континенте и имеют низкую пропускную способность. При высоком времени проверки связи (> 200 мс) и низкой пропускной способности (< 500 кб/с) для пользователей наверняка будет иметь значение общий объем полезных данных и число приемов-передач в приложении. Взгляд на приложение в контексте возможностей этих пользователей важен, поскольку их впечатления будут весьма отличаться от впечатления разработчика.