Отправляет email-рассылки с помощью сервиса Sendsay

.NET: Записки программиста

Рассылка закрыта

При закрытии подписчики были переданы в рассылку "Обзор инструментов SEO-оптимизатора и методов продвижения" на которую и рекомендуем вам подписаться.

Вы можете найти рассылки сходной тематики в Каталоге рассылок.

←   Ноябрь 2007   →
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
Автор
Felix

Статистика

1.618 подписчиков
0 за неделю
←   Все выпуски   →

Время отклика страницы: взгляд со стороны браузера



Время отклика страницы: взгляд со стороны браузера


блог сайта .NET: Записки программиста Подписка на блог сайта .NET: Записки программиста.

Http response time Если вы создали сайт и он стал приобретать популярность в инете - рано или поздно вы столкнетесь с проблемой производительности. Все мы, к сожалению, знаем достаточно много путей, при помощи которых можно увеличить скорость работы. К сожалению - потому что, если бы путей было несколько (в идеале - лучше один, например, наращивание мощности сервера, а еще лучше - кластера :), то и сама проблема по определению была бы проще. Ведь это только сложные проблемы имеют тысячу и один способ решения, причем ни один отдельно взятый способ не помогает решить ее полностью.

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

Но не стоит забывать, что не менее интересные события происходят и по другую сторону фронта - на стороне браузера. Они тоже могут достаточно сильно влиять на то время, когда пользователь сможет увидеть вашу страницу. Причем, что самое интересное, эти события могут вообще быть не связаны с серверной обработкой ASP.NET кода. Это не так заметно для простых сайтов, а вот для порталов (для которых проблема производительности и стоит наиболее остро) каждое обращение к странице - это на самом деле десятки обращений не только к вашему, но и к другим серверам, для получения ресурсов по всем ссылкам, которые встречаются в отданном вами html коде. Это изображения, файлы со стилями, скрипты, а так же ссылки на ресурсы других серверов, отдающих вам разнообразные счетчики, информеры, rss-ы, гаджеты и т.д. Причем список технологий, позволяющих пригрузить ваш сайт контентом других источников растет прямо на глазах. Чего только стоит вклад Google, который успешно перемалывает огромную стоимость своих акций в конкретные технологии, которые позволят остаться Google на плаву, случись какой-нибудь очредной крах дот комов. Вот, кстати, последняя новинка от Google - OpenSocial, API, позволяющий добавлять к вашим сайтам функциональность социальных приложений.

К чему это все? К тому, что иногда очень полезно взглянуть на процесс создания страницы со стороны браузера. Обычно, нас интересуют три вещи:
  1. Размер запрашиваемых файлов. Никогда не сталкивались с дизайном, присланным заказчиком, который включал, ну скажем оч-чень красивую фоновую картинку размером около 500Kb? :)

  2. Время отдачи файлов. Файлы могут:
    • Передаваться от сервера - максимальные затраты по времени.
    • Сервер может возвращать код 304 (not modified). Тогда данные берутся из кеша браузера, затраты по времени - только на запрос к серверу.
    • Данные беруться из кеша сразу, без обращения к серверу - максимально быстрый вариант.

  3. Сервер - источник файлов. Если это запросы к нашему серверу - мы можем обеспечить их доступность. Если же запросы идут к другим серверам - иногда ждать ответа приходится о-очень долго, сервер может быть недоступен или сильно загружен. Как поведет себя в этом случае ваша страница сильно зависит от того, каким образом ссылка размещена в html. В худшем случае страницу вы увидете только после того, как браузер прекратит ожидать ответ по time out.
Чтобы легко оценить, что же все таки творится на стороне браузера, вы можете воспользоваться специальным plug-in для IE - HttpWatch. Он сможет вывести список всех ресурсов, которые запрашивались в процессе формирования страницы, указав их размер, время обращения и другую полезную информацию.

Поскольку лучше один раз увидеть, чем сто раз услышать, давайте посмотрим, как он работает на конкретном примере.

Шаг 1. Скачиваем и устанавливаем HttpWatch (http://httpwatch.com/httpwatch.exe). Он доступен в двух вариантах, бесплатной (Bacis Edition) и платной (Professional Edition). Нам вполне хватит бесплатной версии.

Шаг 2. Выбираем сайт, на примере которого мы будем знакомиться с HttpWatch. Как вариант, я зашел на Google, выбрал "русскоязычные страницы", набрал "портал" - и взял первую ссылку. Это был Украинский портал (я думаю, он оказался на первом месте из-за того, что Google автоматически перекинул меня на www.google.com.ua, российские пользователи получат другой результат).

Шаг 3. Открываем панель HttpWatch (например, нажав Shift+F2) и нажимаем кнопку "Record".

Шаг 4. Набираем в строке запроса http://uaportal.com, ожидаем окончания загрузки и анализируем картинку, полученную по результатам запроса.

Выглядит она примерно так (кликните на картинке, чтобы просмотреть ее полностью):

HttpWatch
Сначала, в виде списка, идут запрошенные ссылки, причем время отклика выводится графически и раскрашивается в зависимости от того, на что тратилось время. Вот, например, такая строка состоит из:

HttpWatch time chart

  1. Первая секция, "DNS Lookup" - время, потраченное на определение IP адреса по доменному имени
  2. Желтая секция, "Connect" - время, потраченное на установку TCP соединения с сервером
  3. Зеленая секция, "Send" - время, потраченное на отсылку http запроса
  4. Красная секция, "Wait" - время ожидания ответа от сервера
  5. Дальше притаилась очень узкая секция "Receive" - получение ответа от сервера. Такая узкая она потому, что в данном случае пришел код возврата 304 (not modified), безо всяких данных
  6. И наконец-то последняя, синяя "Cache Read" секция - время на чтение данных, закешированных в буфере браузера.
Так же, для каждого запроса выводятся объем полученных данных, время отклика, запрашиваемый url и другие полезные вещи.

На нижней закладке "Summary" выводятся общие показатели для страницы: суммарное время отклика, суммарный объем отосланных и полученных данных и т.д. В Professional Edition мы увидим там намного больше полезной информации, но она сможет пригодится для более глубокого анализа, а пока что нам хватит и "бесплатных" данных.

Итак, вернемся к нашему анализу. Вначале результаты могут насторожить: всего было получено 345 Kb данных (html, изображений, стилей, скриптов), время отдачи страницы - чуть больше 51 секунды. Это очень много, даже для такого популярного портала (точнее, тем более, для такого популярного портала). Кроме того, страница явно грузилась быстрее. Заголовок и левая колонка появились у меня почти сразу, центральная область действительно долго оставалась пустой, но не 50, а примерно секунд 15-20.

С объемом все просто - полный размер запрашиваемых данных действительно составляет около 350 Kb, но большая часть из них кешируется и при следующем запросе мы получаем всего 55 Kb - практически весь контент, включая html самой страницы при это берется из кеша.

Просматривая список url, находим ответ и на второй вопрос - почему центральная область грузилась так долго. Это запрашиваемый url "http://s1.obozua.adocean.pl/Ratatouille/ad.js?id=..." с полем Result = ERROR_INTERNET_CANNOT_CONNECT и временем ожидания 21 секунда. Браузер просто не отображал центральную область, ожидая отдачи контента с другого сервера.

Почему же страница отрисовалась полностью примерно через 20, а не 50 секунд? Для этого пройдемся по списку дальше. Вот они, виновники такого результата - еще две ссылки с тем же статусом: http://stats.uaportal.com/counter/s.php/3 и http://stats.uaportal.com/counter/s.php/3. Как раз на 51-й секунде браузер перестал ожидать ответа от последнего сервера. Чтобы понять, почему этого не было заметно, прийдется заглянуть в исходный html страницы. Ага, вот оно, в то время как обращение к первой ссылке формируется скриптом, расположенным в середины страницы, последние две ссылки размещаются в IFRAME и скорость их загрузки не влияет на скорость отображения всей страницы.
Прим. Кстати, когда я заглянул на эту страницу вечером, она отобразилась достаточно быстро, а первая из недоступных ссылок исчезла. Скорее всего, в службе поддержки сайта обратили внимание на задержки в загрузке и выяснив причину (возможно при помощи того же HttpWatch) убрали ссылку. Так что, если вам кажется, что ваши страницы грузятся необоснованно долго - первым делом откройте HttpWatch и проверте партнерские программы, счетчики и другой контент, который собирается на ваш сайт с других серверов.
Что еще полезного может броситься в глаза? На самом деле, это достаточно скользкая область - обычно разработчики знают, что делают, и, если вы видите что-то, неэффективное с вашей точки зрения - скорее всего на это найдутся причины, видимые только изнутри сайта. Но все таки, возможно, java скрипты подобно "Jemplate.js" (JavaScript Templating with Template Toolkit) или изображения более 30-и иконок в заголовке сайта можно было бы брать из кеша браузера не по коду возврата 304, а сразу, указав expiration time в несколько дней и экономя на запросах к web-серверу типа "а что, изображение ld.gif (туфелька, перед ссылкой "Девушка дня") таки еще не обновлялось?".

Ну вот, пожалуй и все, что я хотел рассказать об этой удобной утилите. Удачи вам и легкого решения всех ваших проблем!

В избранное