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

Такие телешоу, как Shark Tank (США), Dragons 'Den (Великобритания) или Die Höhle der Löwen (DHDL) (GER), предлагают молодым стартапам единовременную возможность представить свою продукцию бизнес-магнатам. огромной аудитории. Однако основная прибыль часто заключается не в стратегических инвестициях, предлагаемых членами жюри - только несколько сделок заключены, - а во внимании, повышенном во время шоу: несколько минут в эфире уже могут привлечь сотни тысяч человек. новых посетителей веб-сайта и может повысить базовый уровень активности на несколько недель, месяцев или даже навсегда. То есть, если веб-сайт выдерживает первоначальный всплеск нагрузки и не отклоняет запросы пользователей…

Недостаточно доступности - ключевым моментом является задержка!

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

Существует множество исследований влияния времени загрузки страницы на удовлетворенность клиентов и коэффициент конверсии, подтверждающих это утверждение. Например, Aberdeen Group обнаружила, что одна секунда дополнительной задержки приводит к уменьшению количества просмотров страниц на 11% и потере конверсий на 7%. Но вы также можете спросить Google или Amazon, и они вам ответят то же самое.

Как ускорить работу сайтов

Создавая интернет-магазин для стартапа Thinks, участвовавшего в DHDL, показанном 6 сентября, мы столкнулись с проблемой создания магазина, который мог бы обслуживать сотни тысяч посетителей при постоянной загрузке менее одной секунды. Вот что мы узнали в процессе, а также из нескольких лет исследований производительности баз данных и Интернета.

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

  1. Внутренняя обработка. Веб-серверу требуется время для загрузки данных из базы данных и сборки веб-сайта.
  2. Задержка в сети: каждому запросу требуется время, чтобы пройти от клиента к серверу и обратно (задержка запроса). Это становится еще более важным, если учесть, что средний веб-сайт делает более 100 запросов для полной загрузки.
  3. Обработка веб-интерфейса: устройству внешнего интерфейса требуется время для отображения страницы.

Чтобы ускорить работу нашего интернет-магазина, давайте рассмотрим три узких места по очереди.

Производительность внешнего интерфейса

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

  • DOM: когда браузер анализирует HTML, он постепенно генерирует древовидную модель HTML-тегов, называемую объектной моделью документа (DOM), которая описывает содержимое страницы.
  • CSSOM: как только браузер получает весь CSS, он генерирует древовидную модель содержащихся тегов и классов, называемую объектной моделью CSS, с информацией о стилях, прикрепленной к узлам дерева. Дерево описывает, как оформлено содержимое страницы.
  • Дерево отрисовки. Комбинируя модели DOM и CSSOM, браузер создает дерево отрисовки, которое содержит содержимое страницы и информацию о стилях, которую нужно применить.
  • Макет. На этапе макета вычисляется фактическое положение и размер содержимого страницы на экране.
  • Рисование. На последнем этапе информация о макете используется для раскрашивания фактических пикселей на экране.

Отдельные шаги довольно просты; именно зависимости шагов усложняют работу и ограничивают производительность. Создание DOM и CSSOM обычно оказывает наибольшее влияние на производительность.

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

Перед загрузкой CSS и построением полного CSSOM ничего нельзя отобразить клиенту. Поэтому CSS называется блокировкой рендеринга.

JavaScript (JS) еще хуже, потому что он может получать доступ и изменять как DOM, так и CSSOM. Это означает, что как только тег сценария в HTML обнаружен, построение DOM приостанавливается, и сценарий запрашивается с сервера. После загрузки скрипта он не может быть выполнен до тех пор, пока не будет извлечен весь CSS и не будет построен CSSOM. После построения CSSOM выполняется JS, который, как в приведенном ниже примере, может обращаться и изменять DOM, а также CSSOM. Только после этого можно продолжить построение модели DOM и отобразить страницу для клиента. Поэтому JavaScript называется блокировкой парсера.

Example of JavaScript accessing CSSOM and changing DOM:
<script>
   ...
   var old = elem.style.width;
   elem.style.width = "50px";
   document.write("alter DOM");
   ...
</script>

А JS может быть даже опаснее этого. Есть, например, плагины jQuery, которые получают доступ к вычисленной информации макета HTML-элементов, а затем начинают изменять CSSOM снова и снова, пока он не согласуется с желаемым макетом. Как следствие, браузер должен повторить выполнение JS, отрисовать построение дерева и макет заново, прежде чем пользователь увидит что-либо, кроме белого экрана.

Для оптимизации CRP есть три основных концепции:

  1. Уменьшите количество критических ресурсов. Критические ресурсы - это те ресурсы, которые необходимы для первоначальной обработки страницы (файлы HTML, CSS, JS). Их можно значительно уменьшить, встраивая CSS и JS, необходимые для визуализации части веб-сайта, видимой без прокрутки (называемой над сгибом). Далее JS и CSS надо загружать асинхронно. Файлы, которые нельзя загрузить асинхронно, можно объединить в один файл.
  2. Минимизация байтов. Количество байтов, загружаемых в CRP, можно значительно уменьшить, уменьшив и сжав CSS, JS и изображения.
  3. Уменьшить длину CRP. Длина CRP - это максимальное количество последовательных обратных обращений к серверу, необходимое для получения всех критически важных ресурсов. Он сокращается как за счет уменьшения критических ресурсов, так и за счет минимизации их размера (для получения больших файлов требуется несколько циклов туда и обратно). Что еще помогает, так это включение CSS вверху HTML и JS внизу, поскольку выполнение JS в любом случае блокирует получение CSS и построение CSSOM и DOM.

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

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

  • Профилирование: GTmetrix для измерения скорости страницы, webpagetest для профилирования ваших ресурсов и PageSpeed ​​Insights от Google для выработки рекомендаций по оптимизации CRP для вашего веб-сайта.
  • Встраивание и оптимизация: Critical отлично подходит для автоматического встраивания CSS в верхнюю часть страницы и асинхронной загрузки остальных, processhtml объединяет ваши ресурсы, а PostCSS дополнительно оптимизирует CSS.
  • Минификация и сжатие: мы используем tiny png для сжатия изображений, UglifyJs и cssmin для минификации или Google Closure для оптимизации JS.

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

Интересно, что единственная жалоба в PageSpeed ​​Insights заключается в том, что время жизни кеша скрипта Google Analytics слишком короткое. Итак, Google в основном жалуется на себя.

Производительность сети

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

Когда мы набираем https://thinks.baqend.com в браузере и нажимаем Enter, браузер запускает поиск DNS для определения IP-адреса, связанного с доменом. Этот поиск должен выполняться для каждого отдельного домена.

С полученным IP-адресом браузер устанавливает TCP-соединение с сервером. Для установления связи TCP требуется 2 обхода (1 с TCP Fast Open). При безопасном SSL-соединении для установления связи TLS требуется еще 2 обхода (1 с ложным запуском TLS или возобновлением сеанса).

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

Последний шаг - это загрузка ресурса (в данном случае HTML) за потенциально большое количество циклов туда и обратно. Особенно для новых подключений часто требуется много обходов, потому что начальное окно перегрузки невелико. Это означает, что TCP не использует всю полосу пропускания с самого начала, но увеличивает ее со временем (см. Контроль перегрузки TCP). Скорость зависит от алгоритма медленного старта, который удваивает количество сегментов в окне перегрузки за цикл приема-передачи до тех пор, пока не произойдет потеря пакета. В мобильных сетях и сетях Wi-Fi потерянные пакеты, следовательно, имеют большое влияние на производительность.

Еще одна вещь, о которой следует помнить: с HTTP / 1.1 вы получаете только 6 параллельных соединений (2, если браузеры по-прежнему будут следовать исходному стандарту). Таким образом, вы можете запрашивать до 6 ресурсов одновременно.

Чтобы получить интуитивное представление о том, насколько важна производительность сети для скорости страницы, в httparchive есть много статистики. Например, средний веб-сайт загружает около 2,5 МБ данных при более чем 100 запросах.

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

Оказывается, увеличение пропускной способности сверх 5 Мбит / с вообще не влияет на время загрузки страницы. Но уменьшение задержки отдельных запросов сокращает время загрузки страницы. Это означает, что удвоение пропускной способности оставляет вам то же время загрузки, а уменьшение задержки вдвое дает вам половину времени загрузки.

Итак, если задержка является решающим фактором производительности сети, что мы можем с этим поделать?

  • Постоянные соединения являются обязательными. Нет ничего хуже, чем когда ваш сервер закрывает соединение после каждого запроса, и браузер должен снова и снова выполнять квитирование и медленный запуск TCP.
  • По возможности избегайте переадресации, поскольку они сильно замедляют загрузку вашей начальной страницы. Например, всегда указывайте полный URL-адрес (www.thinks.com, а не thinks.com).
  • Если возможно, используйте HTTP / 2. Он включает в себя push server для передачи нескольких ресурсов для одного запроса, сжатие заголовка для уменьшения размеров запросов и ответов, а также конвейерную обработку и мультиплексирование для отправки произвольного параллельного запроса через одно соединение. С помощью server push ваш сервер может, например, отправить ваш html и сразу после этого отправить CSS и JS, необходимые сайту, не дожидаясь фактического запроса.
  • Установите явные заголовки кеширования для ваших статических ресурсов (CSS, JS, статических изображений, таких как логотипы). Таким образом, вы можете указать браузеру, как долго нужно кэшировать эти ресурсы и когда проводить повторную проверку. Кэширование потенциально может сэкономить вам много обходов и байтов для загрузки. Если не заданы явные заголовки, браузер будет выполнять эвристическое кеширование, что лучше, чем ничего, но далеко не оптимально.
  • Используйте сеть доставки контента (CDN) для кеширования изображений, CSS, JS и HTML. Эти сети с распределенным кешем могут значительно сократить расстояние до ваших пользователей и, таким образом, гораздо быстрее доставлять ресурсы. Они также ускоряют ваше первоначальное соединение, поскольку вы выполняете рукопожатие TCP и TLS с ближайшим узлом CDN, который, в свою очередь, имеет теплые и постоянные внутренние соединения.
  • Рассмотрите возможность создания одностраничного приложения с небольшой начальной страницей, которая асинхронно загружает дополнительные части. Таким образом, вы можете использовать кешируемые HTML-шаблоны, загружать динамические данные небольшими запросами и обновлять разделы страницы только во время навигации.

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

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

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

Производительность серверной части

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

Прежде всего, вам потребуется балансировка нагрузки (например, балансировка нагрузки Amazon ELB или DNS), чтобы назначать входящие запросы одному из серверов приложений. Также следует реализовать автоматическое масштабирование для создания дополнительных серверов приложений при необходимости, а также аварийное переключение для замены неисправных серверов и перенаправления запросов на исправные.

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

Базы данных также должны выдерживать скачки нагрузки и сокращать время обработки, насколько это возможно. В то же время они должны быть достаточно выразительными, чтобы моделировать и запрашивать данные по мере необходимости. Существует множество масштабируемых баз данных (особенно NoSQL), каждая из которых имеет свой набор компромиссов. Дополнительные сведения см. В нашем опросе и руководстве по принятию решений по этой теме:



Базы данных NoSQL: обзор и руководство по принятию решений
Вместе с нашими коллегами из Гамбургского университета мы - это Феликс Гессерт, Вольфрам Вингерат, Штеффен… medium .baqend.com



Интернет-магазин Thinks построен на Baqend, который использует следующий стек серверной части:

Основная база данных, используемая для Thinks, - это MongoDB. Чтобы поддерживать наш истекающий фильтр Блума (используемый для кеширования браузера), мы используем Redis для его высокой записи. мысль. Серверы приложений без сохранения состояния (Серверы Orestes) предоставляют интерфейсы для внутренних функций (хостинг файлов, хранение данных, запросы в реальном времени, push-уведомления, управление доступом и т. Д.) И обеспечивают согласованность кеша для динамических данных. . Они получают свои запросы от CDN, который также действует как балансировщик нагрузки. Интерфейс веб-сайта использует JS SDK на основе REST API для доступа к нему, который автоматически использует полную иерархию кеширования HTTP для ускорения запросов и сохранения кешированные данные в актуальном состоянии.

Нагрузочное тестирование

Чтобы протестировать интернет-магазин Thinks при высокой нагрузке, мы провели нагрузочный тест с двумя серверами приложений на экземплярах t2.medium AWS во Франкфурте. MongoDB работает на двух экземплярах t2.large. Нагрузочный тест был построен с использованием JMeter и выполнен на 20 машинах на программном слое IBM для имитации доступа 200 000 пользователей и просмотра веб-сайта в течение 15 минут. 20% пользователей (40 000) были настроены на выполнение дополнительного процесса оплаты.

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

В совокупности все нагрузочные тесты сгенерировали около 10 миллионов запросов и передали 460 ГБ данных с коэффициентом попадания в кеш CDN, равным 99,8% .

Резюме

Таким образом, хорошее взаимодействие с пользователем основано на трех китах: интерфейс, сеть и производительность серверной части.

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

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

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

Рекомендации по литературе и инструментам

Есть отличные книги на тему веб-производительности и дизайна масштабируемых систем. High Performance Browser Networking Ильи Григорика содержит почти все, что вам нужно знать о работе в сети и производительности браузера, плюс постоянно обновляемая версия доступна для чтения онлайн! Разработка приложений с интенсивным использованием данных Мартина Клеппманна все еще находится в стадии раннего выпуска, но уже входит в число лучших книг в своей области. Он очень подробно описывает большинство основ масштабируемых серверных систем. Designing for Performance Лары Каллендер Хоган - это создание быстрых веб-сайтов с отличным пользовательским интерфейсом, охватывающих множество передовых практик.

Есть также отличные онлайн-руководства, учебные пособия и инструменты, которые стоит принять во внимание. От удобного для новичков курса Udacity Оптимизация производительности веб-сайта до Руководства по производительности для разработчиков от Google до инструментов профилирования, таких как Google PageSpeed ​​Insights, GTmetrix и WebPageTest.

Новейшие разработки в области веб-производительности

Ускоренные мобильные страницы

Google много делает для повышения осведомленности о веб-производительности с помощью таких проектов, как PageSpeed ​​Insights, руководства для разработчиков по ​​веб-производительности, включая скорость страницы как ведущий фактор их рейтинга страницы.

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

AMP выполняет две основные функции:

  1. Веб-сайты, созданные как AMP, используют урезанную версию HTML и загрузчик JS для быстрой отрисовки и асинхронной загрузки как можно большего количества ресурсов.
  2. Google кэширует веб-сайты в Google CDN и доставляет их через HTTP / 2.

По сути, первое означает, что AMP ограничивает ваш HTML, JS и CSS таким образом, что страницы, построенные таким образом, имеют оптимизированный критический путь рендеринга и могут быть легко просканированы Google. AMP применяет несколько ограничений, например, весь CSS должен быть встроен, весь JS должен быть асинхронным, а все на странице должно иметь статический размер (для предотвращения перерисовки). Несмотря на то, что вы можете достичь тех же результатов без этих ограничений, придерживаясь рекомендаций по повышению производительности в Интернете, описанных выше, AMP может быть хорошим компромиссом и помочь очень простым веб-сайтам.

Второй означает, что Google сканирует ваш сайт, а затем кэширует его в Google CDN, чтобы доставить его очень быстро. Содержание веб-сайта обновляется после того, как сканер снова проиндексирует ваш веб-сайт. CDN также учитывает статические TTL, установленные сервером, но выполняет как минимум микрокэширование: ресурсы считаются свежими в течение как минимум одной минуты и обновляются в фоновом режиме при поступлении запроса пользователя. Эффективным следствием является то, что AMP лучше всего подходит в случаях использования, когда контент в основном статичен. Это касается новостных веб-сайтов или других публикаций, которые изменяются только редакторами-людьми.

Прогрессивные веб-приложения

Другой подход (тоже от Google) - прогрессивные веб-приложения (PWA). Идея состоит в том, чтобы кэшировать статические части веб-сайта с помощью сервис-воркеров в браузере. Как следствие, эти части загружаются мгновенно для повторных просмотров, а также доступны в автономном режиме. Динамические части по-прежнему загружаются с сервера.

оболочку приложения (логику одностраничного приложения) можно повторно проверить в фоновом режиме. Если обнаружены обновления оболочки приложения, пользователю будет предложено обновить страницу. Это, например, делается в Inbox от Gmail.

Однако код сервис-воркера, кэширующий статические ресурсы и выполняющий повторную проверку, требует значительных усилий для каждого веб-сайта. Более того, только Chrome и Firefox в достаточной степени поддерживают Service Workers.

Кэширование динамического содержимого

Проблема, от которой страдают все подходы к кэшированию, заключается в том, что они не могут работать с динамическим контентом. Это просто из-за того, как работает HTTP-кеширование. Есть два типа кэшей: на основе недействительности (например, кеши прямого прокси и CDN) и на основе срока действия (например, кеши интернет-провайдеров, корпоративные прокси-серверы и браузер кеши). Кеши, основанные на признании недействительными, могут быть аннулированы заранее с сервера, кэши на основе истечения срока действия могут быть повторно проверены только с клиента.

Сложность при использовании кешей на основе истечения срока действия заключается в том, что вы должны указать время жизни кеша (TTL) при первой доставке данных с сервера. После этого у вас уже не будет возможности выбросить данные. Он будет обслуживаться кешем браузера до момента истечения TTL. Для статических ресурсов это не такая уж сложная вещь, поскольку они обычно меняются только при развертывании новой версии веб-приложения. Следовательно, вы можете использовать классные инструменты, такие как gulp-rev-all и grunt-filerev, для хеширования ресурсов.

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

Подход Бакенда кэш-эскиза

В Baqend мы исследовали и разработали подход к проверке устаревания URL-адреса в клиенте перед его фактическим извлечением. В начале каждого пользовательского сеанса мы извлекаем очень маленькую структуру данных, называемую фильтром Блума, которая представляет собой сильно сжатое представление набора всех устаревших ресурсов. Посмотрев в фильтр Блума, клиент может проверить, может ли ресурс быть устаревшим (содержащимся в фильтре Блума) или определенно свежим. Для потенциально устаревших ресурсов мы обходим кеш браузера и извлекаем контент из CDN. Во всех остальных случаях мы обслуживаем контент непосредственно из кеша браузеров. Использование кэша браузера быстро экономит сетевой трафик и пропускную способность.

Кроме того, мы гарантируем, что CDN (и другие кэши, основанные на недействительности, такие как Varnish) всегда содержат самые свежие данные, мгновенно очищая ресурсы, как только они становятся устаревшими.

Фильтр Блума - это вероятностная структура данных с настраиваемой частотой ложных срабатываний, что означает, что набор может указывать на включение для объектов, которые никогда не добавлялись, но никогда не отбрасывает элемент, который на самом деле был. Другими словами, мы можем время от времени повторно проверять новые ресурсы, но мы никогда не доставляем устаревшие данные. Обратите внимание, что количество ложных срабатываний очень низкое, и это то, что позволяет нам уменьшить площадь установки. Например, нам нужно всего 11 Кбайт для хранения 20 000 отдельных обновлений.

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

Прирост производительности

Все сводится к следующему.

Какого повышения скорости загрузки страниц можно добиться с помощью инфраструктуры кэширования Baqend?

Чтобы продемонстрировать преимущества использования Baqend, мы создали очень простое новостное приложение для каждого из ведущих конкурентов в области backend-as-a-service (BaaS) и измерили время загрузки страницы из разных мест по всему миру. Как показано ниже, Baqend стабильно загружается менее 1 секунды и в среднем в 6,8 раз быстрее конкурентов. Даже когда все клиенты приходят из одного и того же места, где находится сервер, Baqend работает на 150% быстрее из-за кеширования браузера.

Мы создали это сравнение как практическое веб-приложение для сравнения с конкурентами BaaS.

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

Интернет-магазин Thinks - все факты

Когда 6 сентября DHDL (немецкая версия «Shark Tank») транслировался с 2,7 миллионами зрителей, мы сидели перед телевизором и нашими экранами аналитики Google, с нетерпением ожидая, когда основатели Thinks представят свои продукт.

С самого начала их презентации количество одновременных пользователей в интернет-магазине быстро увеличилось примерно до 10.000, но настоящий скачок произошел во время рекламной паузы, когда внезапно более 45000 одновременных пользователей пришли посетить магазин, чтобы купить Towell +:

За 30 минут Thinks в эфире мы получили 3,4 миллиона запросов, 300 000 посетителей, до 50 000. одновременных посетителей и до 20 000 запросов в секунду - все это обеспечивает процент попаданий в кеш 98,5% на уровне CDN и среднюю загрузку ЦП сервера 3%.

Как следствие, время загрузки страницы было менее 1 секунды в течение всего времени, что обеспечивало отличный коэффициент конверсии 7,8%.

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

Резюме

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

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

Подход Baqend заключается в том, чтобы свести веб-разработку к созданию в основном внешнего интерфейса и использования серверных функций полностью управляемой облачной службы Baqend с помощью JS SDK, включая хранилище данных и файлов, запросы (в реальном времени), push-уведомления. , управление пользователями и OAuth, а также контроль доступа. Платформа автоматически ускоряет выполнение всех запросов, используя полную иерархию HTTP-кеша, и гарантирует доступность, а также масштабируемость.

Наше видение в Baqend - это Интернет без времени загрузки, и мы хотим дать вам инструменты для этого.

Попробуйте бесплатно на www.baqend.com.

Интересное обсуждение статьи на Hacknews.

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