Как мы видим, в данном случае создание нового регулярного выражения — весьма ресурсоемкий процесс, поэтому в большинстве случаев лучше обходиться без него. В остальном все браузеры ведут себя достаточно ровно при сопоставлении match, exec и test.
Глава 8. Приложение
8.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:184012.53861
Processing:000.301
Waiting:00 0.301
Totaclass="underline" 184112.43861
В данном случае на один запрос в среднем ушло 41 мс, из них почти все время было затрачено на установление соединения и загрузку данных. Ответа от сервера практически ждать не приходилось.
К такому нагрузочному тестированию стоит подходить крайне осмотрительно: не запускать его на том же самом сервере, где располагается исследуемый сайт (ибо ab сам по себе достаточно «тяжелый» и будет делить физические ресурсы машины с Apache). Если в результате таких тестов задержки оказались весьма высокими и процесс веб-сервера (или CGI) «отъедал» слишком много CPU, то причиной этого зачастую может оказаться необходимость в компиляции скриптов в процессе выполнения при каждом запросе.