company_banner

Кэширование и производительность веб-приложений

Original author: Nick Karnik
  • Translation
Кэширование позволяет увеличивать производительность веб-приложений за счёт использования сохранённых ранее данных, вроде ответов на сетевые запросы или результатов вычислений. Благодаря кэшу, при очередном обращении клиента за одними и теми же данными, сервер может обслуживать запросы быстрее. Кэширование — эффективный архитектурный паттерн, так как большинство программ часто обращаются к одним и тем же данным и инструкциям. Эта технология присутствует на всех уровнях вычислительных систем. Кэши есть у процессоров, жёстких дисков, серверов, браузеров.

image

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

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

Процессорный кэш


Начнём наш разговор о кэшах с самого низкого уровня — с процессора. Кэш-память процессора — это очень быстрая память, которая играет роль буфера между процессором (CPU) и оперативной памятью (RAM). Кэш-память хранит данные и инструкции, к которым обращаются чаще всего, благодаря чему процессор может получать ко всему этому доступ практически мгновенно.

В процессорах имеется особая память, представленная регистрами процессора, которая обычно представляет собой небольшое хранилище информации, обеспечивающее крайне высокую скорость обмена данными. Регистры — это самая быстрая память, с которой может работать процессор, которая расположена максимально близко к остальным его механизмам и имеет небольшой объём. Иногда регистры называют кэшем нулевого уровня (L0 Cache, L — это сокращение от Layer).

У процессоров, кроме того, имеется доступ к ещё нескольким уровням кэш-памяти. Это — до четырёх уровней кэша, которые, соответственно, называются кэшами первого, второго, третьего, и четвёртого уровня (L0 — L4 Cache). То, к какому именно уровню относятся регистры процессора, в частности, будет ли это кэш нулевого или первого уровня, определяется архитектурой процессора и материнской платы. Кроме того, от архитектуры системы зависит то, где именно — на процессоре, или на материнской плате, физически расположена кэш-память разных уровней.


Структура памяти в некоторых новейших CPU

Кэш жёсткого диска


Жёсткие диски (HDD, Hard Disk Drive), применяемые для постоянного хранения данных — это, в сравнении с оперативной памятью, предназначенной для кратковременного хранения информации, устройства довольно медленные. Однако надо отметить, что скорость постоянных хранилищ информации увеличивается благодаря распространению твердотельных накопителей (SSD, Solid State Drive).

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


Кэш жёсткого диска

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

О быстродействии жёстких дисков и оперативной памяти


Разница между временным хранением данных в оперативной памяти и постоянным хранением на жёстком диске проявляется в скорости работы с информацией, в стоимости носителей и в близости их к процессору.

Время отклика оперативной памяти составляет десятки наносекунд, в то время как жёсткому диску нужны десятки миллисекунд. Разница в быстродействии дисков и памяти составляет шесть порядков!


Одна миллисекунда равна миллиону наносекунд

Простой веб-сервер


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


Простой веб-сервер

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

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

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

Кэширование баз данных


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


Простой веб-сервер с базой данных

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

Кэширование ответов веб-сервера


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


Кэш ответов и кэш приложения

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

Мемоизация функций


Сейчас поговорим об оптимизации производительности серверного приложения за счёт мемоизации. Это — разновидность кэширования, применяемая для оптимизации работы с ресурсоёмкими функциями. Данная техника позволяет выполнять полный цикл вычислений для определённого набора входных данных лишь один раз, а при следующих обращениях к функции с теми же входными данными сразу выдавать найденный ранее результат. Мемоизация реализуется посредством так называемых «таблиц поиска» (lookup table), хранящих ключи и значения. Ключи соответствуют входным данным функции, значения — результатам, которые возвращает функция при передаче ей этих входных данных.


Мемоизация функции с помощью таблицы поиска

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

Кэширование в браузере


Теперь перейдём на сторону клиента и поговорим о кэшировании в браузерах. В каждом браузере имеется реализация HTTP-кэша (его ещё называют веб-кэшем), который предназначен для временного хранения материалов, полученных из интернета, таких, как HTML-страницы, JavaScript-файлы и изображения.

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

Перед нами весьма полезная технология, которая даёт следующие преимущества всем участникам обмена данными:

  • Улучшаются впечатления пользователя от работы с сайтом, так как ресурсы из локального кэша загружаются очень быстро. Во время получения ответа не входит время прохождения сигнала от клиента к серверу и обратно (RTT, Round Trip Time), так как запрос не уходит в сеть.
  • Уменьшается нагрузка на серверное приложение и на другие серверные компоненты, ответственные за обработку запросов.
  • Высвобождается некоторая часть сетевых ресурсов, которыми теперь могут воспользоваться другие пользователи интернета, экономятся средства на оплату трафика.


Кэширование в браузере

Кэширование и прокси-серверы


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

▍Шлюзы


Шлюз (gateway) — это прокси-сервер, который перенаправляет входящие запросы или исходящие ответы, не модифицируя их. Такие прокси-серверы ещё называют туннелирующими прокси (tunneling proxy), веб-прокси (web proxy), прокси (proxy), или прокси уровня приложения (application level proxy). Эти прокси-серверы обычно совместно используются, например, всеми клиентами, находящимися за одним и тем же файрволом, что делает их хорошо подходящими для кэширования запросов.

▍Прямые прокси-серверы


Прямой прокси-сервер (forward proxy, часто такие серверы называют просто proxy server) обычно устанавливается на стороне клиента. Веб-браузер, который настроен на использование прямого прокси-сервера, будет отправлять исходящие запросы этому серверу. Затем эти запросы будут перенаправлены на целевой сервер, расположенный в интернете. Одно из преимуществ прямых прокси заключаются в том, что они защищают данные клиента (однако, если говорить об обеспечении анонимности в интернете, безопаснее будет пользоваться VPN).

▍Веб-ускорители


Веб-ускоритель (web accelerator) — это прокси-сервер, который уменьшает время доступа к сайту. Он делает это, заранее запрашивая у сервера документы, которые, вероятнее всего, понадобятся клиентам в ближайшем будущем. Подобные серверы, кроме того, могут сжимать документы, ускорять выполнение операций шифрования, уменьшать качество и размер изображений, и так далее.

▍Обратные прокси-серверы


Обратный прокси-сервер (reverse proxy) — это обычно сервер, расположенный там же, где и веб-сервер, с которым он взаимодействует. Обратные прокси-серверы предназначены для предотвращения прямого доступа к серверам, расположенным в частных сетях. Обратные прокси используются для балансировки нагрузки между несколькими внутренними серверами, предоставляют возможности SSL-аутентификации или кэширования запросов. Такие прокси выполняют кэширование на стороне сервера, они помогают основным серверам в обработке большого количества запросов.

▍Пограничное кэширование


Обратные прокси-серверы расположены близко к серверам. Существует и технология, при использовании которой кэширующие серверы располагаются как можно ближе к потребителям данных. Это — так называемое пограничное кэширование (edge caching), представленное сетями доставки контента (CDN, Content Delivery Network). Например, если вы посещаете популярный веб-сайт и загружаете какие-нибудь статические данные, они попадают в кэш. Каждый следующий пользователь, запросивший те же данные, получит их, до истечения срока их кэширования, с кэширующего сервера. Эти серверы, определяя актуальность информации, ориентируются на серверы, хранящие исходные данные.


Прокси-серверы в инфраструктуре обмена данными между клиентом и сервером

Итоги


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

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

Уважаемые читатели! Какие технологии кэширования вы используете в своих проектах?

RUVDS.com
VDS/VPS-хостинг. Скидка 10% по коду HABR

Comments 21

    0
    Мемоизация функций

    Это скорее всего называется cache aside.
      0

      Не рассмотрены:
      — кэширование DNS ответов на клиенте и на промежуточных серверах.
      — keep-alive соединения от клиента к серверу (не совсем кэширование но принцип похож — повторное использование соединения вместо создания нового соединения).
      — кэширование дескрипторов открытых файлов для случая когда сервер отдает много статики с диска.
      — кэширование выдачи stat().
      — кэширование дерева директорий на диске
      — кэширование информации о клиентском хосте и о параметрах канала от клиента до сервера (так называемый hostcache).
      — кэширование контента после сжатия (gzip).

        0
        Возможно Вы знаете ответ на очень интересующий меня вопрос. Если полгорода вдруг решили посмотреть одно и тоже на Youtube, протянется к каждому прибору своя ниточка с ближайшего DNS сервера или пакеты где-то на промежуточных серверах будут кэшится и потом оттуда раздаваться?
        Заранее признателен за ответ.
          0

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

            0
            Спасибо. Хотя это не совсем ответ на мой вопрос.
              0

              Точный ответ — из полгорода желающих одновременно зайти на youtube значительная часть их заберет резолв из промежуточных кэшей а не с авторитативного сервера. Однако предсказать процент попадания в кэш заранее невозможно.

            0
            А как в данном случае связан ролик с youtube который смотрит полгорода и DNS? И я не очень уловил, что в ответе pae174 не устроило.

            В целом ситуация будет такая. У youtube.com TTL = 30 минут. Т.е. величина средняя и вероятность запроса на разрешение имени высокая. Но учитывая популярность youtube можно сказать, что в DNS кэше провайдера нужная информация будет (именно кэширование инфы, а не конкретных пакетов) и резолвинг произойдет крайне быстро. Поэтому на уровне DNS можно считать, что задержки не будет.

            Далее попадаем на уровень уже самого ролика. Если у провайдера кэширующие сервера есть (а обычно это так и есть), то ролик упадет в кэш конкретного провайдера. После чего будет уже быстро раздаваться клиентам этого провайдера. Очень популярный ролик вероятно упадет в кэш провайдеров всего города. Кроме того есть и другие уровни кэша, чуть выше. Это кэш на магистрали. Еще есть Google Global Cache который могут себе ставить провайдеры.

            Надеюсь ответил на все пункты понятно.

            P.S. А почему интересует данный вопрос?
              0
              Спасибо за ответ. В теории я это себе как-то так и представлял. Но описанная схема хорошо подходит под кэширование по HTTP протоколу. Боюсь, в стрименге всё происходит по другому. Там другие протоколы. Я заметил, что качество картинки при просмотре Youtube и подобных ресурсов со временем подстраивается под пропускную возможность канала. Т.е. какой-то из серверов начинает отправлять другие пакеты, чем в начале просмотра, а в процессе ситуация может снова поменяться.
              Если это делает кэш-сервер, то на нём должно лежать много вариантов одного ролика, грубо говоря. Не хочу Вас обидеть, но картина наверное намного сложнее, чем Вы описали. Не хочу Вас напрягать, но был бы признателен за ссылку на детальное описание этих процессов.
              Ну а интересно мне это потому, что хочется понять, как работают приборы, которые нас окружают.
                0
                По сути стримминг от от статического контента отличается мало. Большой статический файл на клиент уходит кусками и там уже склеивается. Стрим летит на клиент примерно так же, но в отличие от статики клеится на клиенте на лету + важен порядок кусков.

                Т.е. какой-то из серверов начинает отправлять другие пакеты

                Не совсем так. Инициатор соединения клиент, а не сервер. Он и определяет требуемый ему range. А сервер уже отдает ровно то, что от него просят.

                Если это делает кэш-сервер, то на нём должно лежать много вариантов одного ролика

                Не совсем так. На нем много кусков многих роликов. Варианта «вот ролик Х в наборе качества Z, W» обычно нет. Хотя конечно при желании склеить куски одного потока в единственный файл можно.

                признателен за ссылку на детальное описание этих процессов

                Такого описания не может быть в принципе, т.к. какая стратегия применяется кэш сервером зависит собственно от деталей реализации конкретного кэш сервера. И для детального понимания нужно просто читать документацию на конкретное используемое ПО.
                  0
                  Спасибо за Ваше терпение, но позволю с двумя последними пунктами не согласиться.
                  Варианта «вот ролик Х в наборе качества Z, W» обычно нет

                  Я часто наблюдаю, что качество показываемого видео на глазах меняется. Это значит, я думаю, клиент (app) в телевизоре начинает получать контент (наверное типа mp4) с фреймами другого разрешения. А это, в Вашей терминологии кусок N «ролика Х в качестве Z».
                  Такого описания не может быть в принципе,

                  Описание должно быть, поскольку создатели серверной инфраструктуры и разработчики клиентов по показу стриминга должны были выработать общий стандарт.
                  «Будем искать», как говаривал Семён Семёныч.
                    0
                    с фреймами другого разрешения

                    Ну мы же начали с ютуба, так? Так. И там не «с фреймами другого разрешения». Потому что адекватный гугл понимает, что такой поток кэшировать сложнее, чем блоки явно заданные конкретными url.

                    клиентов по показу стриминга должны были выработать общий стандарт.

                    Стандарты есть. Например долгоживущий RTSP. Только на практике все сиииильно и на порядок сложнее, чем некий общий стандарт. Рекомендую поискать статьи/видео от Макса Лапшина.

                    Так же есть webm. Гугл.
                      0
                      Спасибо. Поищу на досуге.
          0
          Для меня, который ничего из этого не знал (даже используемых терминов), полезно.
            0
            Этот кэш используется, когда в ответе сервера содержатся правильно настроенные HTTP-заголовки, указывающие браузеру на то, когда и на какое время он может кэшировать ответ сервера.

            Это единственное, что можно сделать своими руками, если используешь чужую инфраструктуру. Вот про это хотелось бы узнать побольше: стандарты, инструменты, best practices.
            Был бы очень признателен за ссылки.
              0
                0
                Спасибо. Много полезных деталей во второй статье этой серии. В ней я вроде бы нашёл подтверждение своему давнему подозрению, что в мире HTTPS кэширование за пределами сервера не происходит. Учитывая тренд всё делать через HTTPS, про кэширование можно забыть, получается. А что думают специалисты в этой области?
                  0
                  что в мире HTTPS кэширование за пределами сервера не происходит.

                  Это не так. Потому что кэширование на клиенте как было и осталось. В FF в этом легко убедится посмотрев содержимое кэша:
                  about:cache?storage=disk&context=
                  в котором видно много Https ресурсов.
                    0
                    Спасибо. Ценное замечание. Но тогда поведение FF противоречит првилу описанному в указанной наверху ссылке, имхо:
                    Если запрос авторизованный (authorized) или безопасный (то есть, HTTPS), он не будет закэширован.
                      0
                      Не противоречит. Рекомендую читать оригинал. Смотрим: «it won’t be cached by shared caches». Речь о кэширование на промежуточных хостах. Не на клиенте.
                        0
                        Спасибо. Вы правы. Лучше читать первоисточники.
                    0
                    в мире HTTPS кэширование за пределами сервера не происходит
                    Происходит если кэширующий прокси терминирует TLS соединение. Так работает Cloud Flare по крайней мере.

              Only users with full accounts can post comments. Log in, please.