Наверх ▲

High Speed Web Sites At Scale

Бадди Брюэр (Buddy Brewer) Бадди Брюэр (Buddy Brewer) Cоучредителm и генеральныq директор компании Log-Normal, Inc.

Buddy Brewer: Здравствуйте! Меня зовут Бадди Брюэр. Я хотел бы поговорить с вами о разработке высокопроизводительных систем при масштабировании. 

Я занимаюсь тем, что создаю продукты мониторинга веб-производительности. Я работал в одном стартапе в Соединенных Штатах, который разрабатывает соответствующее программное обеспечение. Мы продали нашу компанию более крупной организации, в которой я провел 8 лет. Организация называется Donat. Это одна из двух крупнейших компаний, специализирующихся на мониторинге веб-производительности. Впоследствии я работал только в крупных американских компаниях. 

Совсем недавно вместе с коллегой мы создали компанию Lognormal, Inc. Мы занимаемся следующими вещами. Во-первых, работаем над программным обеспечением, помогая людям измерять параметры веб-сайтов. Во-вторых, оказываем консультационные услуги. Сайт – lognormal.com.

Итак, я хотел бы рассказать о нескольких вещах. Прежде всего, ответить на вопрос: имеет ли значение скорость и чем это подтверждается. Какую роль играет производительность? Кстати, когда речь идет о производительности, прежде всего, я говорю о произодительности сервера front-end. Т.е. о том, что происходит после поступления запросов в базу данных, получения отклика с момента обработки первого HTML-документа, дозагрузки в браузере всех объектов, картинок и JavaScript в процессе взаимодействия пользователя с веб-страницей. 80 % загрузки – это ожидание реакции сервера front-end. Именно здесь обрабатывается основная масса запросов.

Кроме того, нас интересует вопрос: насколько быстро я работаю, насколько быстрый у меня сайт. Также имеет значение некоторые вещи, которые можно сделать с сайтом. Это касается не только небольших, но и крупных веб-сайтов.

Итак, имеет ли значение скорость? 

Пару дней назад я скопировал из Twitter некоторое число комментариев. Они касаются некоторых организаций.

Например, у Банка Америки (крупнейшего розничного банка в Соединенных Штатах) были серьезные проблемы с производительностью веб-сайта. Почему Bank of America сегодня хуже, чем другие банки? "Он слишком медленно работает, многие закрывают счета". Или "почему у вас сайт работает так же медленно, как и ваши банкоматы?" Одного поиска в Twitter оказалось достаточно. 

Например, про веб-сайт Белого дома США можно узнать, что "PHP работает очень медленно, навигация очень запутанная". 

У компании “Domino”, занимающейся продажей пиццы, - просто сумасшествие: "У них глупый сайт, слишком медленный".

Некоторые комментарии касались веб-сайта "Большой Брат". Нередко из-за недостатков в работе сайта организации теряют реальных и потенциальных клиентов.

Результаты исследования, опубликованные в “Forrester Consulting”, свидетельствуют о том, что 5 лет назад время ожидания составляло в среднем 4 секунды. Сейчас – 2 секунды. Что касается исследований мобильной производительности и производительности за рабочим столом, то их пока не существует. 

Все зависит, конечно, от скорости подключения. Пользователи хотят получить отклик быстро. Например, задержка загрузки страницы, достигающая одной секунды, уменьшает количество ее просмотров на 11 %, снижает удовлетворенность клиентов на 16 % и сокращает конверсию на 7 %. 

Amazon.com обнаружил, что каждые 100 миллисекунд задержки обходятся им в 1 % продаж.

Быстродействие сайта все-таки имеет значение. Следующий вопрос: как насчет моего сайта? Он быстрый или нет? Как это можно узнать? Есть несколько способов.

Первый способ - синтетический мониторинг. Он касается понятия использования автоматического веб-агента. Это компьютерная система, которую можно использовать на веб-сайте. Вы посещаете свою страницу, заходите в приложение и измеряете, сколько времени уходит на определенные действия. Скажите, кто из вас пользуется подобными схемами "водопада" (англ. waterfall)? Треть аудитории. Хорошо. 

Синтетический мониторинг – это исторически первый подход, который был изобретен для мониторинга производительности. Обычно эти тесты проводятся на протяжении определенного периода времени из различных географических точек, т.е. там, где обычно находятся ваши клиенты. Это дает определенные преимущества. 

Каковы преимущества синтетического мониторинга? Во-первых, время отклика на уровне объектов. Во-вторых, производительность для третьих сторон. В-третьих, провайдеры или социальные сети, их виджеты. Также синтетический мониторинг дает отличный способ управления производительностью этими сторонами, как все это влияет на сайт. В конечном счете пользователю все равно, каким CNN вы пользуетесь или к какой социальной сети подключены. Это ваш сайт, ваш бренд. Если производительность от этого страдает, даже если это вина третьих лиц, все равно обвинять будут вас.

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

Так как синтетический мониторинг является также формой тестирования, то можно отдать агенту команду куда-то пойти на сайте. Его можно использовать для исследования производительности таких мест, которые пользователи посещают редко. Если трафик в подобных местах невелик, это может иметь критическое значение для вас. 

Так как "синтетика" - исторически самый ранний подход, он хорошо применим к браузерам IE 7, более старым версиям Firefox и др. 

Конечно, синтетический мониторинг не обходится без недостатков. Географическое покрытие - ограничено. Мы - американская компания, у которой много точек мониторинга в Соединенных Штатах. Но, по мере реализации наших услуг в Китае и России, мы обнаружили, что недостаточно иметь одного-двух агентов в стране. Нужно нечто более серьезное. Если ваши клиенты находятся в местах, удаленных от агента, то это окажется белым пятном в плане обслуживания клиентов. 

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

Другой используемый подход - это мониторинг реальных пользователей. 

Вместо программного агента используются реальные пользователи, трафик.

Что важно? Пользовательский мониторинг показывает правду. Перед вами - пользователи, их кошельки. Нельзя быть ближе к реальности.

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

Кроме того, у вас - полный охват браузеров. Например, я не знаю синтетического мониторинга, который бы хорошо давал с Safari. С реальным – практически все, где есть JavaScript. Для вендоров третьих сторон трудно выиграть в этом аспекте. Единственный способ, как в это сделать, - это произвести впечатление на пользователей. Учитывая, что все современные браузеры имеют встроенный JavaScript, то они одинаково хорошо работают как в мобильной, так и в настольной среде.

Также можно измерять производительность в контексте бизнес-целей. Я думаю, практически все здесь имеют определенную маркетинговую аналитику на своих сайтах (сведения о количестве просмотренных страниц, посетителей и другие показатели). Данные показатели можно отслеживать в контексте производительности приложений. Например, какое количество посетителей конвертируется за 2 или 3 секунды. Имеет ли смысл вкладывать средства в оптимизацию сайта?

Что еще появилось на рынке? Я с удовольствием об этом поговорю. Появился новый стандарт, который называется «временем навигации». Так как вы собираете данные с использованием JavaScript в браузере, то вы не получаете ничего, пока JavaScript не начнет действовать. Например, разрешение DNS - в первое время, SSL-приветствие и пр. С навигационным временем невозможное стало возможным. В этом можно убедиться на примере трех наиболее популярных браузеров: NineNine, Chrome и Firefox.

Если зайти на высоконагруженный сайт, можно открыть окно PerformanceTiming и определить временные штампы. Например, я знаю время начала навигации и время получения первого байта отклика.

Таким образом, если я произведу вычитание, то смогу определить, что на операцию ушло 399 миллисекунд. Обратим внимание на временные показатели конца загрузки. Если из них я вычту время получения первого байта, то замечу, что разница составляет, например, больше двух секунд.

Итак, между 399 миллисекундой и 2 секундой должно загрузиться огромное количество картинок и произойти много интересных вещей (разрешение DNS или страница SSL). Также важно, используете ли вы библиотеки реальных пользователей и браузеры в своей производительной или тестовой среде.

Каковы недостатки мониторинга реальных пользователей? Пока нет времени отклика на необъектном уровне, потому что время навигации сегодня можно использовать в последних версиях трех наиболее популярных браузеров. Есть еще одна спецификация, которой пока нет, но она скоро увидит свет. Она позволит вам измерять отдельно время отклика для реальных пользователей. Так что это будет огромное событие в сфере производительности и обработки страниц третьих сторон. Если смотреть на спецификацию в плане времени навигации, можно увидеть не только это, но еще и целый ряд рабочих групп со своими спецификациями. В частности, это касается уровня объектов.

Также можно добавлять код к сайту (как и JavaScript), пакеты аналитики. Чем крупнее сайт, тем больше процессов и тем лучше все это встраивать в очереди. Так как вы измеряете характеристики реальных пользователей (особенно это касается очень крупных сайтов), то нужно вести навигацию по вопросам защиты частных данных. Здесь важно время отклика. Но всякий раз, когда вы собираете данные о ваших пользователях, возможны юридические последствия. Об этом должны подумать специалисты в вашей компании.

Наконец, нет данных для back-end по старым браузерам, поскольку это внесено только в последние версии браузеров.

 

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

Для мониторинга реальных пользователей также существует сайт boomerang.js. Его можно установить у себя на странице (демонстрация операций). Он будет собирать много интересной информации бесплатно.

Что делает boomerang? Он проверяет, как пользователи используют пропускную способность. Если у них очень плохое соединение, то неудивительно, что загрузка сайта занимает много времени. Если канал хороший, а сайт загружается медленно, то это уже проблема сайта. 

Boomerang не только измеряет время загрузки сайта. Он производит измерения таким образом, что пользователь этого не чувствует. Boomerang собирает необходимые данные, включая информацию о пропускной способности, и сопоставляет временные и пропускные параметры. Полученное заносится в cookies. Если пользователь выходит в Интернет в другом месте (например, не из дома, а из интернет-кафе), тогда будет произведен пересчет пропускной способности канала.

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

Вы размещаете дополнительную информацию, используя BeaKen, конфигурируя Apache, чтобы соответствующим образом получать ответ. Запрос реализуется стандартным образом. Информацию можно фильтровать и использовать для статистического анализа. Это бесплатные возможности для мониторинга.

В заключение хочу привести пару примеров по повышению производительности. Кто такой Стив Саудерс из Google? Это главный специалист по производительности. Он - автор двух книг по по этой теме. Книги располагаются в открытом доступе. Напишите следующую фразу: «оптимизация производительности Google». Вы получите достаточно ссылок. 

 

Что особенно интересно для крупных сайтов? Во-первых, по мере возможности используется кэш браузера. Httparchive.org – очень интересный сайт, который я вам рекомендую. На сайте содержится интересная статистическая информация. Можно использовать ее для самостоятельных анализов. Httparchive использует webpage.org, чтобы оценивать производительность крупнейших сайтов.

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

Можно установить определенный срок или некое относительное число - и нужный объект будет находится в кэше в течение соответствующего времени. Это логотипы, баннеры и прочее. E-Tag и реализация в Apache стоит по умолчанию. Inode в Apache используют как компонент E-Tag, который также рассчитывается по умолчанию.

Если вы думаете, что используете кэш надлежащим образом, Apache скажет, что это делается автоматически. Все равно это связано с определенным узлом в вашем кластере, откуда пришел запрос. Если пользователь приходит к вам на сайт с другого узла кластера, тогда E-Tag не будут совмещаться. Опять получится, что кэш не используется в отношении пользователя. 

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

 

Кроме того, компрессия, снижение веса, ограничение запросов – это все тоже очень полезно.

Можно организовать тестирование для поддержки Gzip. По результатам исследования Google, 15 % браузеров, которые должны поддерживать Gzip, не сообщают об этом. Будут использовать Gzip или нет - об этом не сказано.

Почему? Зачастую мешают прокси. Они перенаправляют соответствующий поток. Это мешает компрессии, декомпрессии. Кроме того, работают личные сетевые экраны. 

Что сделал Google? Он встроил на страницы скрытый iframe. Там содержится Gzip-контент с кодом, который создают cookies у клиента. По следующим запросам можно cookies посмотреть и увидеть браузеры, в которых написано, что они не поддерживают Gzip, хотя они поддерживают. Можно соответствующим образом осуществить компрессию изображения. 

Зачастую там содержатся вещи, которые не нужны. Например, метаданные по jpeg или графика – логотипы (это не фотографии, там не очень большое количество цветов). Можно сократить количество цветов. Есть сайт, который поможет с этим. CSS Sprites позволяет большое количество малых изображений совместить в одно, что сокращает количество запросов по изображениям и общий объем.

 

Что можно сказать о третьих сторонах? О них всегда нужно помнить. Допустим, на странице есть 12-13 разных доменов. Но что касается конечных пользователей, если сайт работает медленно, очень трудно сваливать всю вину на Twitter или Facebook.

Перейдем к оптимизатору контента. Браузеры становятся все более разными. Некоторые поддерживают ряд параллельных соединений, некоторые поддерживают больше таких соединений. Можно использовать Domain-Sharding, чтобы перемещать нагрузку по различным серверам для установления большого количества параллельных соединений. Если это уже сделано, тогда можно применить шардирование, что облегчит работу.

Что можно сказать об Internet Explorer, Firefox и Chrome в данном контексте? Оптимизаторы находятся между сайтом и пользователем. Они работают как компиляторы. Можно использовать программу и посмотреть, как быстро будут протекать операции на различных процессорах в зависимости от компилятора. Можно попытаться переместить нагрузку на третью сторону. 

Оптимизаторов много, их всегда можно использовать.

Три вещи, о которых я хотел еще сказать в конце выступления.

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

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

В-третьих, производительность надо рассматривать в качестве отдельной функциональной особенности. Это способствует повышению удовлетворенности клиентов.

Вопросы и ответы

Вопрос из зала: Спасибо за презентацию. Вы много говорили о сборе информации, но ничего - о ее анализе. Какие инструменты вы используете для этих целей?

Buddy Brewer: Да, я много говорю о том, как собирать данные. Что делать с ними после сбора? Это область, где не так много инструментов. Webpage test предоставляет не только агент, который собирает данные, но и некоторые возможности для анализа. Временные ряды при этом не анализируются. Насколько я знаю, планируется это исправить. Я работаю с компаниями, которые реализовали свои версии. Это сделать несложно, но занимает определенное время. 

Что касается мониторинга реальных пользователей, то меня и моего бизнес-партнера интересует создание инструментов для обработки данных о сервере back-end. Часть этих вещей будет находиться в открытом доступе, часть будет предоставляться за плату. Сейчас с точки зрения анализа не так много что есть. Если вы сами попытаетесь разработать соответствующие инструменты, то уйдет довольно много времени. 

Вопрос из зала: У вас была красивая картинка водопада. Это бета-версия?

Buddy Brewer: Нет. Это уже не бета-версия. Просто набираете адрес. Вот, собственно, пример: webpagetest.org, highload.ru. Данное программное обеспечение можно взять и установить где угодно, если вы хотите проводить аналогичные измерения. 

Вопрос из зала: Насколько важно с точки зрения пользователя, чтобы все страницы загружались за две секунды? Скажем, 90 % страниц удовлетворяют этому критерию, а 10 % нет.

Buddy Brewer: Все страницы должны одинаково быстро грузиться, быстрее двух секунд, иначе клиенты начнут уходить. Что я бы порекомендовал в подобной ситуации? 

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

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

Вопрос из зала: Почему все боятся E-Tag? По-моему, у вас было в презентации, что его не надо использовать. Поясните, пожалуйста. 

Buddy Brewer: Вопрос непростой. Если правильно использовать E-Tag, то ничего плохого не произойдет. Но в случае с Apache, когда он рассчитывает E-Tag, по-моему, используется последняя модифицированная дата и путь к файлу. 

Я могу гарантировать, что если у вас будет 100 веб-серверов в кластере, то этот конкретный файл может иметь последний штамп времени изменения именно из-за физической точки. Каковы последствия? В результате величина этого E-Tag будет изменяться, потому что они тоже изменялись в кластере. Кластер обнаруживает, что варианты E-Tag - разные, и отсылает его обратно. 

Не то чтобы E-Tag так плохи. Просто так с ними обращаются два крупных веб-сервера. Их можно переконфигурировать или просто не использовать. Можно использовать кэш-контроль. 1.1 и "стекают" в 1.1. Большое спасибо за вопросы.

Комментарии

Нет ни одного комментария

Только пользователи могут оставлять комментарии

Возможно, вам будет интересно:

Александр Сербул

Александр Сербул

C 2011 года курирует направление контроля качества интеграции и внедрений ООО «1С-Битрикс», активно участвует как архитектор и разработчик в проектах компании, связанных с высокой нагрузкой и отказоустойчивостью («Битрикс24»), консультирует партнеров и клиентов по вопросам архитектуры высоконагруженных...

Александр Демидов (1С-Битрикс) делится опытом использования "облачного" хранилища и рассматривает хранилище как элемент масштабируемой отказоустойчивой архитектуры.

Сергей Аверин

Сергей Аверин

Руковожу разработкой проектов в Баду. Программирую server-side. Конференционный маньяк. Среди проектов, которые я делал — Хабрахабр, dirty.ru, trendclub.ru. Специализируюсь на больших/сложных веб-проектах.

twitter: twitter.com/ryba_xek
facebook: facebook.com/ryba.xek

Выбор хранилища данных — сложная задача, с которой часто сталкиваются разработчики. Чаще всего результат выбора — это компромисс. Я расскажу о собственном опыте, набитых «шишках», рассмотрю важные, на мой взгляд, связанные с этой задачей проблемы.

Ярослав Городецкий

Ярослав Городецкий

Генеральный директор CDNvideo. В Интернете и телекоме с 1996 года. Обожает придумывать и запускать новые продукты и услуги.

Ярослав Городецкий (CDNvideo) делится своим опытом построения сети доставки контента, работающей в России, СНГ и Западной Европе.