Приложение
Обзор аналитических инструментов
Давайте рассмотрим ряд приемов, позволяющих самостоятельно провести анализ производительности сайта. К ним можно отнести как проверку времени создания страницы на сервере, так и измерение фактического времени загрузки страницы у пользователя.
Измеряем эффективную ширину канала пользователей
Можно легко измерить реальную пропускную способность канала для пользователей исследуемого сайта. И в том случае, если пользователи загружают страницу существенно медленнее, чем могли бы (учитывая физические ограничения на их канал), возможно, стоит применить меры к исправлению этой ситуации.
Прежде чем давать браузеру любые ссылки на внешние объекты (<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 + '<=' +
((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/
Вышеуказанным способом мы запускаем стресс-тест для сайта http://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 ). Можно посмотреть на список файлов и оценить, что отнимает большую часть времени при загрузке страницы:
К сожалению, здесь размер встроенных изображений отображается неверно. И нет данных о том, в какую стадию загрузки попал той или иной файл. Работает только под Firefox.