Метод повышения производительности интернет-приложений на основе кэширования обработчиков событий

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

Для решения проблемы могут использоваться три подхода: оптимизация запросов, масштабирование, кэширование.

Оптимизация запросов – по сути фундаментальна, но потребует индивидуального подхода к каждому запросу. Это может привести к реструктуризации данных. Оптимизация потребует серьезного анализа [1, с. 102], а если проблем много, то скорость реализации будет очень низкой. Помимо того, если проблемы оптимальны, то их оптимизация не даст нужного результата.

Масштабирование как правило использует два основных подхода: шардинг и репликацию [2, с. 38].

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

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

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

Одна из основных проблем кэширования – выбор того, какие данные кэшировать [3, с. 22]. Если речь идет о динамических данных, то следует помнить о возможности их изменения в персистентном уровне. В таком случае, данные в кэше могут стать неактуальными и пользователь получит неверную информацию. Решением может стать инвалидация данных в кэше. Однако любая стратегия инвалидации – лишь компромисс между производительностью кэша и сложностью его реализации. Помимо этого, часто возникающая инвалидация может нейтрализовать положительный эффект от оптимизации. Однако компромисс возможен, так как эффективность кэширования – это время, затраченное на обработку определенного количества ресурсов.

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

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

Пример таких данных: агрегированные ранее данные, утверждение статьи, пользовательские данные (настройки, права, прочее) и другие.

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

Еще одна важная проблема – компромисс между объемом памяти, используемой для кэша и эффективностью самого кэша [4, с. 114]. Небольшой объем кэша не позволит хранить большой пул данных, что снизит эффективность, слишком большой кэш будет неэффективно использовать ресурсы.

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

Инвалидация кэша по времени является наиболее простым методом контроля с элементами эвристики. Суть в том, что кэш будет очищать часть старых и неактуальных элементов к моменту записи в память новых данных. Такой метод прост в разработке, а его инкапсуляция на уровне подсистемы кэширования позволит легко интегрировать. Этот метод требует взвешенного TTL – времени жизни кэшированного элемента. Но его определение не всегда тривиально из-за неоднородности данных. Решение проблемы лежит в принципе "разным данным – разное время". Но это повысит сложность разработки. Поэтому рассмотрим другие способы оптимизации.

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

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

Введение кэша второго и третьего уровня (L2-L3), сглаживает разрыв между производительностью и первым уровнем кэша и RAM.

Введение L2 и L3 решало нынешнюю проблему. Можно предположить, что введение подобного в приложение окажет похожий эффект. Но тут возникает проблема – определение оптимального количества слоев, от которых напрямую зависит сложность реализации. Недостаточность слоев не даст результата, а переизбыток перегрузит систему.

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

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

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

Можно сформулировать основные принципы адаптированного кэширования:

- кэшируемые данные должны максимально редко изменяться, но часто использоваться;

- инвалидация по времени упростит интеграцию;

- многоуровневая система – компромисс между простотой и быстротой.

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

Была реализована четырехуровневая подсистема кэширования, которая включает в себя:

- кэш сервера в RAM.

- взаимодействие с RAM через MemoryCache;

- кластерное хранилище Redis, шестиузловая система (3 master, 3 slave)

- azure Table (хранилище, данные не удаляются);

- read only mode БД;

- время хранения данных: RAM – 15 минут, Redis – 48 часов;

- service Bus для записи в Azure и БД.

Проведено двухсерийное нагрузочное тестирование: с выключенным и включенным кэшем. Результаты на картинках 1 и 2.

Рисунок 1. График времени ожидания обработки запроса при выключенной подсистеме кэширования

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

Рисунок 2. График времени ожидания обработки запроса при включенной подсистеме кэширования

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