Кэш vs куки
Что такое кэш (cache) и куки (Cookie), а также чем они различаются, должен знать любой тестировщик программного обеспечения. К тому же, этот вопрос нередко задают на собеседованиях, особенно когда речь идет о малоопытных соискателях, претендующих на позицию Junior/Trainee. Об этом — наша статья.
Кэш представляет собой промежуточный буфер памяти и место на жестком диске персонального компьютера, где хранится информация о ранее посещенных веб-страницах, включая изображения и прочие данные.
Представьте, что вы впервые зашли на какой-нибудь сайт. Вы просматриваете разные страницы, при этом вся информация (графическая, текстовая, мультимедийная) загружается на сайт с соответствующего сервера. Когда кэширование подключено, данные с посещенных вами страниц сохраняются на жестком диске в специально отведенной для этого папке. Ниже можно посмотреть, где хранится кэш браузера Google Chrome:
Когда вы посещаете этот сайт второй и последующие разы, ваш веб-браузер проверяет содержимое сайта, а потом выполняет загрузку лишь новой информации. Остальная же информация берется для отображения именно из вашего кэша. Для чего? Во-первых, для повышения скорости загрузки сайта, во-вторых, для снижения нагрузки на интернет-соединение, ведь доступ к данным в кэше осуществляется быстрее.
Надо ли чистить кэш?
Безусловно, да. Делать это следует периодически по следующим причинам: 1. Кэш занимает место на жестком диске, а свободного пространства, как известно, много не бывает. Если долго не чистить кэш, это скажется на скорости работы вашего ПК. 2. Кэш важно чистить в целях безопасности. Недоброжелатели могут попытаться взломать ваш компьютер через кэш. 3. Кэш надо чистить в целях поддержки актуальности данных. Считается, что если кэш не чистить от слова совсем, есть вероятность пропустить обновления на сайтах, которые вы посещаете. 4. Кэш важно чистить для обеспечения корректной работы приложений и онлайн-сервисов. Это важный момент для тестировщика. Когда возникают проблемы на стороне пользователя, не забудьте, прежде всего, почистить кэш браузера.
Куки тоже хранятся на персональном компьютере пользователя и представляют собой данные (как правило, их небольшой фрагмент). Вот, где хранятся куки браузера Хром:
Этот фрагмент отправляется на ваш компьютер веб-сервером при первом посещении веб-сайта. Согласно международным правилам, вы должны дать согласие на прием куки, впрочем, скорее всего, вы делали это неоднократно, вот, как это может выглядеть:
Главное отличие куки от кэша заключается в том, что каждый раз, когда вы повторно заходите на конкретный сайт, с которого вам был когда-то отправлен конкретный куки, веб-клиент (обычно, это ваш веб-браузер) пересылает этот фрагмент данных web-серверу в составе HTTP-запроса.
Как правило, применение куки упрощает следующие процедуры: • аутентификацию пользователя; • хранение персональных настроек и предпочтений; • отслеживание состояния сеанса доступа; • ведение статистики и т. д.
Вот несколько примеров использования куки на практике: 1. Авторизация на сайте. Как известно большинство сайтов имеют авторизацию (ввод пароля, логина, телефона, почты и т. п.). Cookie могут применяться сервером для опознания ранее аутентифицированных пользователей. 2. Корзина в интернет-магазинах. Если не использовать куки, при выборе товара и переходе на новую страницу товар может исчезнуть. 3. Настройки. К примеру, вы выставили нужные настройки региона, языка и т. д. Без куки они могут сброситься и вернуться в статус значений по умолчанию.
Надеемся, теперь вы понимаете разницу между кэшом и куки.
Как почистить кэш и куки?
Куки можно почистить в инструментах разработчика. Для Google Chrome нажмите F12, потом вкладку Application (вы должны находиться на странице сайта, куки которого собрались чистить) . Для очистки делаем следующее:
То есть надо будет выбрать адрес сайта под строкой Cookie, нажать правую кнопку мыши, а потом «Clear».
Теперь кэш. Есть разные способы его очистки, но мы продолжим использовать «Инструменты разработчика». Переходим на интересующий веб-сайт, нажимаем F12, потом опять Application. Далее выбираем Clear storage и скроллим вниз. Смотрим, чтобы стояла галочка напротив Cashe storage и нажимаем кнопку Clear site Data. Обратите внимание, что тут же можно почистить сразу и куки, да и не только их.
Напоследок, дадим еще несколько советов начинающим тестировщикам: — в режиме «Инкогнито» все данные тянутся напрямую с сервера, кэш не используется! — нажав Ctrl+F5 в обычном режиме браузера, вы также «потянете» все данные не из кэша браузера, а напрямую с сервера.
Тестирование мобильных приложений: tips & tricks
Наша новая статья представляет собой список рекомендаций и советов. Из неё вы узнаете:
- как облегчить процесс тестирования мобильных приложений в целом;
- о специфике работы с сетью, внутренними и внешними сервисами, платформах iOS и Android;
- какие процессные решения и изменения позволят вам развиваться быстрее и вводить культуру тестирования в отделе разработки;
- какие существуют полезные инструменты и решения для тестирования, отладки, мониторинга и миграции пользователей.
Как облегчить процесс тестирования?
- Набор интеллект-карт на все случаи жизни: test insane, ministry of testing
- Эвристики, мнемоники: I SLICED UP FUN (моя любимая), COP FLUNG GUN, SFDPOT, LONG FUN CUP
- Попросите клиентских и серверных разработчиков выводить в удобный и понятный интерфейс для просмотра логов все запросы к серверу и ответы от него. Так будет проще анализировать запросы и ответы от сервера, выявлять дубликаты, находить более удобные способы обновления данных. Например, для обновления части профиля разработчик может перезапрашивать весь профиль вместо использования более легковесного запроса. В ситуациях, когда непонятно, где проблема, комбинация серверных и клиентских логов в большинстве случаев поможет разобраться с проблемой быстрее.
- Научитесь добавлять клиентские логи самостоятельно (впрочем, помощь девелопера всё же может понадобиться) — избыток логов тоже вреден и загрязняет консоль.
3. Используйте «обезьянок» для поиска крашей и зависаний, пока вы тестируете функционал более осмысленно. Наиболее эффективно комбинировать обезьянок и средства для снятия телеметрии для ускорения локализации проблемы, например, с TestFairy. С недавних пор TestFairy поддерживает и iOS, но пока функционал ограничен.
- Android: Application/UI Monkey Exerciser
- iOS: UIAutoMonkey/CrashMonkey (основывается на UIAutoMonkey). К сожалению, AntEater совсем забросили — на сайте ошибка 404. Последний раз фиксил баги и обновлял для iOS8 я сам (если вдруг кому интересно) — разработчики так и не решились передать исходный код в open source, хотя просили их неоднократно.
- У Android с бета-программой дела пока намного лучше, чем у iOS: можно приглашать (или ждать заявок от) пользователей через Google+. Количество бета-пользователей ограничено 10 000.
- У iOS c TestFlight (который купила Apple) есть некоторые искусственные ограничения: максимум 2000 пользователей, серьёзное «ревью» первой бета-версии. Сервисы дистрибуции тоже можно использовать для бета-программы. Отличный обзор сервисов дистрибуции: 1, 2, 3, 4.
- включить Network Link Conditioner;
- включить логирование потребления трафика и энергии;
- удобнее тестировать iAd рекламу.
7. Если приложение поддерживает портретный и ландшафтный режим, то уделите смене ориентации девайса особое внимание. Это может вызывать краши, утечки памяти, возвращение к предыдущему состоянию.
- На iOS проверяется правильность работы с памятью (не обратились ли вы к неправильному участку памяти; не обновился ли экран, пока он был невидим), утечки памяти.
- На Android могут быть утечки памяти, т.к. предыдущую активность (activity) что-то «держит».
- запросы должны отменяться, если они не завершены;
- ответ сервера на удаленный из памяти (невидимый) скрин не должен «крашить» приложение.
10. Заполняйте оперативную память девайса перед запуском приложения. Это поможет, во-первых, провести стресс-тестирование и проверить скорость работы, а во-вторых — проверить сохранение и возобновление состояния приложения (куда мы вернемся после сворачивания приложения, запустятся ли все нужные сервисы).
- Есть шанс познать дзен 🙂
- Позволяет работать медленно с приложением, что иногда вскрывает баги.
- Если в приложении случится краш или exception — оно остановится, и тогда можно будет подозвать разработчика для отладки «не отходя от кассы».
Работа с сетью
- нестабильном соединении;
- отсутствующем соединении;
- исключительно медленной скорости (1-2Kb/s);
- отсутствии ответа от сервера;
- неправильном ответе сервера (мусор или ошибки);
- смене типа соединения Wi-Fi — 3G — 4G — Wi-Fi на лету.
- кастомную прошивку для роутера. В свое время меня здорово спасала прошивка Tomato для Linksys WRT54G. Роутер стоил копейки, а с помощью прошивки можно выставлять необходимую скорость Wi-Fi на лету без потери соединения с девайсами;
- прокси; ; — легко ставится на Mac и встроен в iOS с версии 6.0. Им можно «зашейпить» трафик и раздать с помощью создания точки доступа как на iOS-устройстве, так и на Mac;
- для Android можно использовать пресеты скорости соединения в эмуляторе или более гибко настроить через netspeed.
Работа с данными приложений, внешними и внутренними сервисами
1. Если есть сторонний сервис — он обязательно подведет. Недавняя авария у FB повлияла на работу некоторых приложений и сайтов. Например, пару версий назад приложение Habrahabr «расшаривало» статьи с блокированием UI без индикатора активности. В момент, когда «тормозил» Facebook или Интернет, «шаринг» вешал всё приложение до тех пор, пока процесс не завершался.
Лучше заранее выявить максимальное количество внештатных ситуаций и продумать шаги для их устранения: предусмотреть обработку неожиданных ответов (ошибки, мусор, отсутствие ответа, пустой ответ) от сторонних сервисов с индикацией проблемы пользователю, добавить таймауты к необходимым реквестам и т.д.
2. Если есть сторонние библиотеки — они обязательно будут вызывать проблемы. В частности Twitter, PayPal, Facebook довольно часто содержат в себе баги. Как пример, в одной из версий Twitter SDK был краш при получении 503 ошибки от собственного бэкенда — библиотека просто падала и утаскивала за собой приложение. Facebook SDK тоже нередко падает на Android (можно видеть в краш-алертах процесс под названием com.facebook.katana время от времени).
- ошибка 404 вернулась в HTML-формате;
- в ответе 200 есть HTML или JS;
- вернулся пустой ответ;
- сервер на запрос к API отвечает стандартной заглушкой веб-сервера (“It works!” в случае nginx);
- вернулась пустая структура данных (JSON, XML, PLIST);
- вместо одной структуры данных вернулась другая (HTML вместо XML);
- вернулся ведущий не туда или невалидный URI.
Помимо работы над стабильностью приложения, в вышеуказанных случая важно давать пользователю какой-либо визуальный отклик: алерт, тост-нотификацию, плейсхолдеры вместо данных и т.д.
- сделали все URL-ы конфигуриемыми и вынесли в отдельную сущность, чтобы команда разработки или тестирования могла легко пересобрать приложения с определёнными URL-ами для обновляемых данных;
- далее изменили все необходимые файлы и заменили ими уже существующие (вручную или с помощью простейших скриптов). Для отката на предыдущую версию можно написать ещё один скрипт, который запишет эталонные файлы (также можно воспользоваться версионированием файлов, которую предоставляет Dropbox).
Android
1. Выставьте кастомные разрешения экрана эмулятора — это позволит выявить проблемы с layout, если у вас есть определённая нехватка девайсов или нужно проверить, правильно ли написан layout. Также разрешение экрана и плотность пикселов можно редактировать через ADB и на физическом девайсе, например, на Nexus 10.
2. Если клавиатура переопределена (используется кастомная), то уделите этому дополнительное внимание. Бывают как ошибки клавиатур, которые не удаётся обойти, так и логические или графические ошибки.
3. Staged rollout позволит легко найти проблемы, которые могли пропустить при тестировании релизной версии: можно зарелизиться на 5-10% и помониторить графики и краши, при необходимости — откатиться или перевыложить версию с фиксом.
4. Используйте do not keep activities при тестировании и убедитесь, что приложения готовы к неожиданным завершениям активностей, что может вести к крашам или потере данных.
1. Проверьте, не переопределены ли стандартные жесты. Например, при активации «Универсального Доступа» активируются дополнительные жесты, они могут конфликтовать с жестами вашего приложения (например, трёх- и четырёхпальцевый жест).
2. Также уделяйте внимание сторонним клавиатурам. Например, в iOS9 есть баг, который приведет к крашу приложения, если в модальном окне в WebView вводить текст с помощью сторонней клавиатуры.
3. Покажите разработчикам сервис rollout.io, который позволяет патчить некоторые краши на продакшене, переопределять параметры, показывать алерты с извинениями или делать некоторые кнопки неактивными. Нас он уже спасал не один раз.
4. Для интерактивного тестирования верстки или проверки того, что все скрины убрались из иерархии, можно использовать стандартные средства Xcode или Spark Inspector, RevealApp.
5. Попросите интегрировать в меню отладчика вызов Memory Warning. Его обычно вешают на определённый жест (тап несколькими пальцами, нажатие на строку состояния или навигации) или на кнопки регулирования громкости. Это нужно, чтобы проверить адекватность поведения приложения при Memory Warning, подчищает ли оно за собой ресурсы и насколько корректно это делается. Например, у нас был неприятный баг, когда после Memory Warning наш Image service выгружал картинку из памяти и на экране оставалась заглушка.
Налаживаем процессы
Эти советы помогут вам быстрее продвигаться в тестировании мобильных приложений и научат обходить подводные камни при взаимоотношениях с разработчиками.
1. Введите культуру Pre-QA. Перед отправкой тикета на ревью сядьте вместе с разработчиком за его машину и потестируйте 5-10 минут фичу под отладчиком на одном-двух девайсах — большинство самых глупых ошибок найдется сразу. Это также позволяет обучить разработчиков базовым навыкам тестирования: как минимум они будут повторять за вами действия, как максимум — вникнут и будут тестировать более осмысленно. Никому не хочется допускать глупые ошибки и выставлять их на общее обозрение.
2. Хотя бы бегло просматривайте diff-ы каждой ветки (фичи) и задавайте как можно больше вопросов разработчикам.
Таким образом вы, во-первых, поднимите свой престиж как тестировщика — вы пытаетесь разобраться в коде и областях, которые затронуты этой фичей. Даже сейчас тестировщики мобильных приложений иногда воспринимаются разработчиками как обезьянки, которые тыкают в телефон и жонглируют ими чтобы «уронить» приложение.
Если нет свободных девелоперов — вы можете выступить ревьювером: разработчик во время объяснения работы фичи иногда сам находит недостатки или кейсы, которые он не учел.
Во-вторых, вы начнёте постепенно изучать язык программирования и будете лучше понимать, что происходит «под капотом» приложения.
3. Изучите жизненный цикл сущностей приложения и самого приложения (Activity для Android 1, 2, 3; ViewController для iOS 1, 2, 3) для понимания, из какого в какое состояние может переходить экран приложения и оно само. Чем лучше вы знаете работу приложения изнутри, тем более полно сможете его протестировать.
4. Если у вас есть приложения для iOS и Android, то важно соблюдать правильный баланс ресурсов для их тестирования.
- У Android есть staged rollout (поэтапное внедрение). Android-приложение можно перевыложить хоть в тот же день или откатить staged rollout (до 50% раскладки можно полностью откатить на предыдущую версию). Но не стоит перевыкладываться очень часто, т.к. пользователи начнут жаловаться и ставить низкие оценки;
- Для iOS перевыкладка производится, в лучшем случае, через expedited review (которым очень не рекомендуют злоупотреблять). Приложение будет перевыложено:
- самое раннее — в тот же день (обычно в in review уходит в тот же день, но доступно к выкладке только на следующий);
- в худшем случае, если не разрешили expedited review, срок увеличится до 5-10 дней.
Разное
- в случае появления критичного бага, пропущенного при разработке и тестировании;
- при быстром обновлении интересующей нас версии для:
- запуска фичи одновременно на всех платформах (также пригодится, если изменения ломают обратную совместимость);
- более быстрых и равномерных результатов A/B тестирования;
- разгрузки серверной команды, которая вынуждена поддерживать устаревшие версии API из-за определённого количества пользователей, пользующихся (очень) старой версией приложения.
- мягкий (soft-update), когда на экране есть кнопки «Обновиться» и «Пропустить» (экран можно спрятать на 24 часа; так же в этом режиме можно просить пользователей включить автообновление приложений для iOS и Android в настройках системы — некоторая часть пользователей отключает автоапдейты);
- жесткий (hard-update) — на экране показывается только кнопка «Обновить», которая ведет сразу на страничку нашего приложения в магазине.
- графики daily/monthly/… active users, чтобы быстрее реагировать на аварии;
- системы сбора и анализа краш-логов: Crashlytics (теперь часть Twitter Fabric), HockeyApp, Crittercism, BugSense (теперь часть Splunk);
- системы обратной связи от пользователей через приложение (встроенные feedback-формы или отправка письма) с возможностью отправки описания девайса и скриншотов;
- статистики использования приложения (GoogleAnalytics, Flurry, Splunk, Heatmaps.io, MixPanel);
- дайджестов скачиваний, группировки отзывов, понимания, где и когда вас зафичерили (AppAnnie — куплен Distimo).
4. Также не стоит забывать о временных поясах и локации пользователей. Возможно, ваше приложение не рассчитано на работу в определённых странах (хотя и выложено там по ошибке или вы, как пользователь, приехали на время в другую страну). Местоположение на iOS можно «фейкать» в настройках симулятора (Debug > Locations), а на Android есть приложения, позволяющие это делать.
Если приложение работает с данными и есть несколько дата-центров в разных временных зонах, необходимо убедиться, что все работает правильно и не возникает коллизий при переключении между дата-центрами.5. Научитесь обновлять и «даунгрейдить» прошивки — платформы фрагментированы, особенно Android и Blackberry. Облачные сервисы хороши, но они стоят денег, поэтому не все компании имеют возможность ими пользоваться из-за недостатков финансирования или политики безопасности.
6. Нашли баг после выкладки фичи, но приходится перевыкладывать новую версию? В этом случае вам поможет включение, отключение или модификация фич на лету. В наших приложениях очень много фич можно выключить со стороны сервера напрямую или, в зависимости от решения команды, с помощью специального интерфейса.
Заключение
Такой перечень рекомендаций, подходов и инструментов, на наш взгляд, может быть полезен как начинающим, так и опытным тестировщикам мобильных приложений. Надеюсь, разработчики и менеджеры тоже почерпнут что-то полезное для своих целей.
Составляя этот список, мы с коллегами основывались на собственном опыте и будем рады увидеть ваше мнение в комментариях.
Основные принципы кэширования веб-приложений
Веб-приложения прошли большой путь с самого начала. Традиционный процесс создания веб-приложений проходит через несколько этапов проектирования, разработки и тестирования перед тем, как они будут готовы. Как только ваше приложение будет выпущено, реальные пользователи будут постоянно к нему обращаться. Если ваше приложение станет популярно, оно будет доступно по крайней мере нескольким миллионам пользователей ежедневно. Хотя звучит многообещающе, это повлечет за собой дополнительные расходы.
Помимо цены, некоторое время займет выполнение сложных расчетов и операций чтения и записи. Это значит, что ваш пользователь должен дождаться завершения операции. Если ожидание окажется слишком долгим, это может сказаться на пользовательском опыте.
Разработчики систем используют несколько стратегий, чтобы устранить эти проблемы. Кэширование — одно из них.
Кэширование в веб-приложениях — что это?
Веб-кэш — это компонент, способный временно хранить HTTP-ответы, которые могут быть использованы для последующих HTTP-запросов при соблюдении определенных условий.
Веб-кэширование — это ключевая дизайнерская особенность HTTP-протокола. Оно предназначено для снижения сетевого трафика во время увеличения предполагаемой ответной реакции в целом. Кэши находятся на каждом этапе перемещения контента — от исходного сервера к браузеру.
Если говорить простым языком, веб-кэширование позволяет повторно использовать HTTP-ответы, которые были сохранены в кэше, с HTTP-запросами аналогичного характера. Давайте рассмотрим простой пример, когда пользователь запрашивает с сервера определенный тип продукта (книги). Можно предположить, что весь этот процесс займет примерно 670 миллисекунд. Если чуть позже в тот же день пользователь выполнит этот же запрос вместо того, чтобы снова повторить те же вычисления и потратить 670 миллисекунд, HTTP –ответ может вернуться к пользователю. Это значительно сократит время отклика. В реальности это может составить менее 50 миллисекунд.
Преимущества кэширования
Существует несколько преимуществ кэширования с точки зрения потребителя и поставщика.
Снижение затрат на пропускную способность
Как было сказано ранее, содержание может быть кэшировано в различных точках HTTP-запроса от потребителя к серверу. Когда содержание кэшировано ближе к пользователю, запрос пройдет меньшее расстояние, что снизит затраты на пропускную способность.
Улучшенный отклик
Поскольку кэши хранятся ближе к пользователю, необходимость в полном цикле обращения к серверу пропадает. Чем ближе кэш, тем быстрее будет ответ. Это напрямую окажет положительное воздействие на пользовательский опыт.
Повышенная производительность на том же оборудовании
Ввиду того, что кэш обслуживает подобные запросы, ваше серверное оборудование может сосредоточиться на запросах, которым необходима вычислительная мощность. Агрессивное кэширование может еще больше повысить производительность.
Доступность контента даже при сетевых сбоях
При использовании определенных стратегий кэширования в случае сбоя сервера контент будет передан конечным пользователям из кэша за небольшой период времени . Так они смогут выполнить основные задачи без сбоя.
Недостатки кэширования
Кэш удаляется во время перезапуска сервера
Каждый раз, когда сервер перезапускается, кэш-данные также удаляются. Это происходит потому, что кэш нестабилен и может исчезнуть при потере источника питания. Однако вы можете придерживаться стратегий, в которых вы регулярно записываете кэш на свой диск, чтобы сохранить кэшированные данные даже во время перезагрузки сервера.
Обслуживание устаревших данных
Одна из основных проблем кэширования — это обслуживание устаревших данных. Устаревшие данные — это необновленные сведения, которые содержат предыдущую версию данных. Если вы кэшировали запрос продуктов, но в то же время, менеджер удалил четыре продукта, пользователи получат списки продуктов, которые не существуют. Такое положение сложно выявить и исправить.
Где можно кэшировать?
Как упоминалось ранее, контент может быть кэширован в различных местах на пути запроса.
Кэш браузера
Веб-браузеры имеют небольшой собственный кэш. Обычно браузер устанавливает политику, которая определяет наиболее важные элементы для кэширования. Это может быть пользовательский контент или контент, который будет ценен для загрузки и, вероятно, будет восстановлен. Чтобы отключить кэширование источника, вы можете установить заголовок ответа, как показано ниже:
Прокси-серверы для промежуточного кэширования
Любой сервер, расположенный между устройством потребителя и вашей серверной инфраструктурой может кэшировать содержимое по своему желанию. Подобные кэши могут обслуживаться интернет-провайдерами или другими независимыми сторонами.
Обратный кэш
Вы можете реализовать собственную инфраструктуру кэширования в своих внутренних службах. Для этого вы можете воспользоваться такими платформами, как Redis или Memcache.
Прочитайте более подробно о Cache-Control в этой статье.
Источник: MDN DocsЧто можно кэшировать?
Все типы контента можно кэшировать, но это не значит, что это всегда необходимо.
Совместимость с кэшем
Ниже изложены типы контента, которые являются наиболее подходящими для кэширования. Они редко меняются и поэтому могут кэшироваться в течение более длительного периода времени:
· Изображения, логотипы и иконки
Умеренно совместим с кэшированием
Нижеприведенный контент может быть кэширован, но следует соблюдать особую осторожность, так как этот тип контента может регулярно меняться:
- Часто изменяемые JS и CSS
- HTML-страницы
- Запрос контента с файлами cookie
Никогда не кэшируются
Данные типы контента нельзя кэшировать, иначе у вас могут возникнуть проблемы с безопасностью:
· Конфиденциальный контент, например — банковская информация и т.д.
· Чаще всего пользовательские данные не должны кэшироваться, так как они регулярно обновляются
Зачем нужна стратегия кэширования?
В реальном мире вы не сможете реализовать агрессивное кэширование, так как большую часть времени оно будет возвращать устаревшие данные. Поэтому необходима специальная стратегия кэширования, чтобы сбалансировать использование долгосрочного кэширования и реагирование на требования меняющегося сайта путем реализации подходящих алгоритмов удаления кэша. Поскольку каждая система уникальна и обладает определенным набором требований, необходимо потратить время на создание стратегии кэширования.
Идеальная стратегия кэширования состоит в том, чтобы идти по тонкой грани, которая способствует агрессивному кэшированию, когда это возможно, оставляя отверстия для аннулирования записей в будущем при внесении изменений.
Цель данной статьи — ознакомить вас с базовыми знаниями кэширования для веб-приложений. Мы пропустили такие темы, как заголовки управления, инфраструктура кэширования, руководство по разработке кэш-стратегии и т.д., так как они слишком сложны для этого введения.
Кэш — Основы Redis
На сегодняшний день время отклика на запрос является критичной метрикой для любого проекта. Пользователи не очень любят, когда web-страница формируется долго (несколько секунд или дольше). Поэтому разработчики стремятся уменьшить время ответа на запрос клиента, для чего прибегают к кэшированию.
Представим, что разрабатывается торговая платформа и есть личный кабинет с аналитикой сделок пользователя. Нужно выводить количество сделок, прибыль, средний оборот и тд. Большинство метрик являются агрегационными, то есть их нужно высчитывать. Если использовать только РСУБД, то среднее время ответа будет сотни миллисекунд, а при большой нагрузке — секунды. Можно подключить подходящие аналитические базы данных, но чаще всего это слишком дорого в средних проектах.
Самая распространенная практика решения сегодня — это кэш. Сложные вычисления кэшируются, то есть записываются в оперативную память. Обращение к оперативной памяти займет сотни наносекунд, примерно в миллион раз быстрее, чем вычислить данные из РСУБД. Новая схема взаимодействия будет включать кэширующий сервер. Алгоритм следующий:
- клиент делает запрос
- бекенд проверяет кэш. Если значение есть в кэше, то оно просто возвращается клиенту
- если значения в кэше нет, то сервер вычисляет все из базы, записывает числа в кэш и отдает клиенту. Теперь все последующие запросы будут возвращать результаты вычислений из кэша
Подводные камни
Как у любого решения в разработке, кэширование — не серебряная пуля и имеет свои недостатки. Несколько моментов, которые стоит держать в уме при использовании кэша:
- приложение должно уметь работать без кэша. Кэширующий сервер упал или недоступен? Пользователь все равно должен получать все данные просто с небольшой задержкой. Завязывать какую-то логику продукта на кэш (например, хранить данные аналитики только в кэше) — нельзя, потому что это ненадежное хранилище.
- с введением нового звена в архитектуру всегда следует усложнение разработки и поддержки продукта. Проверка и запись значений в кэше — это дополнительная логика в коде, которая требует дополнительного времени на тестирование и исправление потенциальных ошибок.
- сколько времени должно храниться значение в кэше? Что делать, если значение невалидно, так как пользователь открыл новую сделку или получил прибыль? Эти вопросы будут возникать постоянно, и в каждом проекте ответы будут уникальными.
Redis как кэш
Redis чаще всего используют именно как кэширующий сервер. Он имеет богатый встроенный функционал для этих целей. Рассмотрим основные команды, с помощью которых кэшируют значения в Redis.
Кэширование
Представим, что нужно записать количество сделок пользователя в кэш. Запишем, что у пользователя с ID 33 имеется 5 сделок. Используем обычную команду set :
Данные записаны. Однако они будут храниться вечно до следующей перезагрузки сервера или пока не будут удалены вручную. Одно из основных свойств кэша — это то, что он хранится короткий промежуток времени. Данных может быть много, а ресурсы серверов не бесконечны. К счастью в Redis можно указать время жизни ключа (время экспирации), по истечении которого ключ будет удален. Для этого достаточно добавить постфикс ex количество_секунд к команде set :
Проверить, через сколько ключ удалится можно командой ttl :
В данном случае ключ user:33:deals_count исчезнет через 115 секунд.
Если попытаться получить значение спустя это время, то вернется пустой ответ:
Время жизни можно задавать не только в секундах, но и в миллисекундах с помощью префикса px количество_миллисекунд :
Проверка времени жизни осуществляется командой pttl :
Вывод выше показывает, что ключ user:33:deals_count исчезнет через 7484 миллисекунд (
Инвалидация кэша
Любой кэш может стать неактуальным раньше времени жизни. В нашем примере со сделками это может произойти при возникновении новой сделки у пользователя. В этом случае нужно удалить ключ в кэше, чтобы при следующем запросе произошел пересчет значения. Может возникнуть вопрос: а почему бы просто не добавить значение в имеющийся ключ? В данном примере это было бы наилучшим решением, но действовать необходимо не «в лоб». При увеличении значения двумя командами get + set может получиться неконсистентное состояние (подробнее эта проблема будет рассмотрена в следующем уроке). Также обновление значения не всегда возможно, например, в случае если значение — это среднее арифметическое.
Удаление ключа происходит командой del :
Вернувшееся значение 1 означает, что ключ существовал и был успешно удален. Если ключа не было, то вернулся бы 0.
Иногда требуется удалить тысячи ключей за раз. Например, у поставщика цен на акции произошел сбой и все сделки за период сбоя оказались недействительными. В этом случае нельзя использовать N вызовов команды del , потому что это будет выполняться очень долго и заберет все ресурсы Redis. Для множественного удаления существует команда unlink , которую можно безопасно использовать в продакшен-среде:
Все ключи для удаления указываются через пробел. Стоит учитывать, что ключи удаляются асинхронно, то есть могут существовать после unlink короткий промежуток времени.
Резюме
Открыть доступ
Курсы программирования для новичков и опытных разработчиков. Начните обучение бесплатно