Обзор аналитических инструментов 1

Давайте рассмотрим ряд приемов, позволяющих самостоятельно провести анализ производительности сайта. К ним можно отнести как проверку времени создания страницы на сервере, так и измерение фактического времени загрузки страницы у пользователя.

Измеряем эффективную ширину канала пользователей

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

Прежде чем давать браузеру любые ссылки на внешние объекты (<img src=»…»>, <link rel=»stylesheet» href=»…»>, <script src=»…»> и т.д.), мы можем записать текущее время. После загрузки всей страницы можно будет его вычесть и получить, таким образом, полное время загрузки страницы (за исключением получения HTML-файла и задержек, связанных с первым соединением с сервером). Полученное время можно затем добавить к вызову любого URL (например, картинки), расположенной на вашем сервере.

JavaScript-код для этого будет выглядеть примерно следующим образом:

<html>
<head>
<title>…</title>
<script type=»text/javascript»>
<!—
var began_loading = new Date().getTime();
window.onload = function(){
    new Image().src = ‘/timer.gif?u=’ + self.location + ‘&t=’ +
    ((new Date().getTime() — began_loading) / 1000); };
// —> </script>
<!—
Здесь будут размещаться ссылки на любые внешние JS- или CSS-файлы, главное, чтобы они шли ниже верхнего блока
// —>
</head>
<body>
<!— Здесь идет обычное содержание страницы
// —>
</body>
</html>

Эта конструкция произведет примерно следующую запись в лог-файл: 127.0.0.1 — — [28/Oct/2006:13:47:45 -0700] «GET /timer.gif?u=http://example.com/page.html&t=0.971 HTTP/1.1» 200 49 …

В этом случае, как можно понять из записи, загрузка оставшейся части страницы http://example.com/page.html заняла у пользователя 0,971 секунды. Если предположить, что всего на странице было загружено файлов общего размера в 57842 байтов, 57842 байтов * 8 битов в байте / 0,971 секунды = 476556 битов в секунду (4б5 Кбит). Такова эффективная пропускная способность канала при загрузке этой страницы. Если у пользователя физический входящий канал 1,5 Мб, значит, есть большой простор для увеличения скорости загрузки.

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

Apache Benchmark и JMeter

Утилита ab из пакета для Apache (устанавливается под Linux обычно вместе с самим Apache) позволяет устроить простой тест для производительности сервера. Стоит заметить, что это будет чисто серверная производительность, а не клиентская.

Мы можем запустить тест с помощью команды

ab -c10 -n1000 http://www.website.ru/

Вышеуказанным способом мы запускаем стресс-тест для сайта www.website.ru. При проведении тестирования главная страница сайта будет скачана 1000 раз (модификатор -n1000) с использованием 10 параллельных соединений (модификатор -c10). Если запустить такой же тест для статических файлов, то можно диагностировать медленное обслуживание обычных запросов (обычно статические файлы отдаются со скоростью порядка 1000 в секунду). Если же сервер отвечает дольше, чем 5-10 миллисекунд при генерации страницы, значит, стоит хорошо разобраться, на что уходит процессорное время.

Основная характеристика здесь — это время, ушедшее на установление соединения. Например, следующее значение будет говорить о хорошей реакции сервера на пользовательские запросы:

Time per request: 40.599 [ms]
Connection Times (ms)
    min mean[+/-sd] median max
Connect: 18 40 12.5 38 61
Processing: 0 0 0.3 0 1
Waiting: 0 0 0.3 0 1
Total: 18 41 12.4 38 61

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

К такому нагрузочному тестированию стоит подходить крайне осмотрительно: не запускать его на том же самом сервере, где располагается исследуемый сайт (ибо ab сам по себе достаточно «тяжелый» и будет делить физические ресурсы машины с Apache).

Если в результате таких тестов задержки оказались весьма высокими и процесс веб-сервера (или CGI) «отъедал» слишком много CPU, то причиной этого зачастую может оказаться необходимость в компиляции скриптов в процессе выполнения при каждом запросе.

Для более мощного и точного тестирования стоит посмотреть в сторону другой программы — Apache JMeter, которая предназначенная для нагрузочного тестирования различных сетевых сервисов и приложений, не ограничиваясь только HTTP. Это, по сути, универсальная и более продвинутая замена ab, только более требовательная к пользователю, так как содержит ряд мощных инструментов, которые может быть под силу правильно применить только профессионалу. Кстати, JMeter позволяет не только тестировать веб-приложения, но и любые другие сетевые сервисы — SMTP, POP и даже базы данных через JDBC. Если в планах стоит постоянное использование тестирования, то стоит обратить внимание именно на это приложения: из бесплатных и открытых — это, пожалуй, самое гибкое и мощное решение.

Кэширование на сервере

Такое программное обеспечение, как eAccelerator/xCache/ZendOptimizer для PHP, mod_perl для perl, mod_python для python и др., могут кэшировать серверные скрипты в скомпилированном состоянии, существенно ускоряя загрузку нашего сайта. Кроме этого, стоит найти профилирующий инструмент для используемого языка программирования, чтобы установить, на что же тратятся ресурсы CPU. Если удастся устранить причину больших нагрузок на процессор, то страницы будут отдаваться быстрее и появится возможность выдавать больше трафика при меньшем числе машин.

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

Можно также рассмотреть использование memcached для кэширования на стороне сервера. Memcached создает очень быстрый общий кэш, который объединяет свободную оперативную память всех имеющихся машин. Клиенты к нему перенесены на большинство распространенных языков.

Web Developer Toolbar для Firefox

Данный инструмент позволяет проанализировать размеры всех загруженных на странице файлов (чтобы его открыть, нужно кликнуть или выбрать через правый клик панель инструментов Web Developer -> Information -> View Document Size). Можно посмотреть на список файлов и оценить, что отнимает большую часть времени при загрузке страницы:

SpeedUpYourWebsite.v1.2_img_38

Рис. 38. Результаты анализа загрузки сайта в Web Developer Toolbar

К сожалению, здесь размер встроенных изображений отображается неверно. И нет данных о том, в какую стадию загрузки попал той или иной файл. Работает только под Firefox.

Firebug NET Panel для Firefox

Другим, более популярным инструментом для анализа загрузки сайта в Firefox является Firebug (со встроенной NET Panel). Он отслеживает все пакеты, которые передает или запрашивает Firefox, позволяя тем самым построить вполне точную диаграмму загрузки страницы. Естественно, позволяет увидеть и все HTTP-заголовки (как запроса, так и ответа) для полученных файлов. К сожалению, на данный момент Firebug не учитывает время, затраченное на DNS-запросы, редиректы и отображение страницы.

Однако ситуация обещает исправиться, да еще и кардинальным образом: уже сейчас доступна альфа-версия Firebug 1.4a1, в которой для каждого загружаемого объекта страницы теперь выводится полная статистика затрачиваемого времени. Конечно, есть еще куда стремиться: можно добавить и общую диаграмму загрузки, и затраты времени на все компоненты вместе, а не по отдельности. Но и этот шаг будет весьма значительным.

SpeedUpYourWebsite.v1.2_img_39

Рис. 39. Результаты анализа загрузки сайта в Firebug Net Panel 1.4a1

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

Но давайте рассмотрим загрузку страницы в текущей версии инструмента:

SpeedUpYourWebsite.v1.2_img_40

Рис. 40. Результаты анализа загрузки сайта в Firebug Net Panel

На диаграмме загрузки для webo.in хорошо отслеживается стадия предзагрузки (заканчивающаяся c получением файла c.css?20081010). На этой же стадии у пользователя оказываются загруженными 2 изображения (оба запрошены через new Image().src, одно из них — «на будущее). После того, как страница появилась в браузере пользователя (на это ушло порядка 200 мс с момента запроса страницы), сработало событие готовности документа к дальнейшим действиям. По этому событию Firefox запросил 3 файла: d.css?20081010, g.js?20080920 и j.js?20080924.

g.js (являясь сжатым скриптом Google Analytics) отправил данные о посещении на сервер статистики с помощью файла __utm.gif . Стоит заметить, что все вызовы внешних ресурсов из HTML-файла осуществлялись при использовании DOM-методов добавления элементов, и это позволило максимально их распараллелить. Далее Firefox (так как кэш был отключен) запросил файл b.png повторно (основываясь уже на данных из файла d.css, содержащего информацию о стилях для фона элементов). При наличии в кэше файл просто отобразился бы на странице, и запроса не произошло.

После получения всех файлов на странице сработало событие window.onload, по которому загрузился последний файл (скрытая таблица стилей, используемая на других страницах сайта). Для пользователя это произошло абсолютно прозрачно: страница уже была полностью готова к взаимодействию, не требовалось никакого дополнительного времени ожидания.

В данном случае размер страницы составляет порядка 100 Кб в сжатом виде и около 200 Кб в несжатом. Однако это не помешало ей загрузиться (если не брать в расчет некоторые файлы «на будущее» и отключенное кэширование) менее чем за 500 мс.

Yslow для Firebug для Firefox

В качестве полезного дополнения к Firebug (для Firefox) стоит рассмотреть и YSlow. На данный момент этот инструмент, пожалуй, является наиболее адекватным для анализа скорости загрузки страницы.

Все аспекты производительности разбиты на разделы. В случаем невыполнения каких-либо советов дается ссылка на полный его вариант на английском языке. Естественно, что советы не идеальны, и в некоторых случаях допустимо не следовать им буквально. Однако при прочих равных условиях более высокая оценка (максимум 100) соответствует более оптимизированному сайту.

SpeedUpYourWebsite.v1.2_img_41

Рис. 41. Результаты анализа загрузки сайта в YSlow

Posted in Разгони свой сайт.