Я бы хотел использовать возможности Varnish для кеширования моего приложения с интенсивным использованием php, которое обслуживает около 400 тысяч человек в день.
Приложение извлекает данные поиска, запуская несколько потоков, которые скручивают XML, так что вы можете представить, что новые потоки порождаются много, а потоки остаются открытыми в течение нескольких секунд, в результате чего страница загружается за пару секунд.
Кеш каждой страницы результатов поиска значительно ускорит взаимодействие с пользователем.
Итак, вот основа для моего вопроса.
Наши страницы результатов поиска требуют отслеживания кода конверсии. Таким образом, пользователь переходит из источника / ссылки A на нашу страницу domain.com/search/?q=something&source=A, соответствующий код отслеживания конверсии (относящийся к ссылке A) выбирается и выводится на страницу. Cookie также удаляется, поэтому в следующий раз, когда пользователь возвращает страницу, проверяет, существует ли cookie, если да, выбирает отображение правильного кода конверсии в HTML.
Таким образом, отслеживание конверсий работает как во время сеанса, так и вне его.
Вопрос в том, можно ли в этом сценарии использовать лак для кеширования, учитывая наши требования к файлам cookie? Можем ли мы каким-то образом настроить VCL для обработки этих файлов cookie, и если да, то что мы должны написать?
Спасибо
Я считаю, что самый простой способ подумать об эффективности и применении Varnish - это мыслить комбинациями. Каждая переменная создает экспоненциально больше комбинаций. Вкратце, это следующие переменные: хост, URI и заголовки / файлы cookie.
например это разные объекты в кэше Varnish
domain.com/search/?q=something
domain.com/search/?q=something&source=A
domain.com/search/?q=something&source=B
domain.com/search/?q=something&source=A + nocookie
domain.com/search/?q=something&source=A + cookie1
domain.com/search/?q=something&source=A + cookie2
domain.com/search/?q=something&source=B + nocookie
domain.com/search/?q=something&source=B + cookie1
domain.com/search/?q=something&source=B + cookie2
ТЕМ НЕ МЕНИЕ: Пока источники не сильно различаются, и пока сервер не несет ответственности за вывод различного контента в зависимости от источника, использовать Varnish должно быть довольно просто ... но только если вы сначала выполните некоторые манипуляции.
Поскольку у вас есть возможность манипулировать большей частью клиентского запроса с помощью Varnish, вы можете фактически удалить & source = A или & source = B из запрошенного URI перед его отправкой на внутренний сервер. Это по сути превращает все эти запросы:
domain.com/search/?q=something&source=A + nocookie
domain.com/search/?q=something&source=A + cookie1
domain.com/search/?q=something&source=A + cookie2
domain.com/search/?q=something&source=B + nocookie
domain.com/search/?q=something&source=B + cookie1
domain.com/search/?q=something&source=B + cookie2
только в это:
domain.com/search/?q=something
Из 6 промахов и без попаданий теперь 1 промах и 5 попаданий.
Итак, клиент запрашивает это у Varnish:
domain.com/search/?q=something&source=A + cookie1
и Varnish запрашивает это у бэкэнда (например, Apache) для первого запроса:
domain.com/search/?q=something
а затем кэшируется для последующих запросов (тем самым значительно повышая процент попаданий). Это называется «нормализацией».
Затем, конечно, статический файл JavaScript будет выполнять свою работу, ссылаясь на строки запроса URI и выполняя некоторые манипуляции с DOM (что-то вроде того, что делает Google Analytics) на основе исходной строки запроса.
Таким образом, для клиента будет поддерживаться & source = A, и JavaScript может использовать это соответственно; и до тех пор, пока JavaScript отвечает за динамическое изменение содержимого, у вас не должно возникнуть проблем с удалением всех или большей части файлов cookie или строк запроса из вашего запроса до того, как Varnish отправит запрос на бэкэнд.
Вы также можете кэшировать свои XML-запросы, если они являются запросами GET.
По сути, название игры с Varnish связано с «нормализацией» бэкэнд-запроса, так что URI / куки / заголовки, которые не влияют на то, что возвращается с сервера, должны обрабатываться иначе, как нормализованные, перед отправкой на бэкэнд.
Переформатирование URI в Varnish: https://stackoverflow.com/questions/3547384/can-i-reformat-my-url-parameters-with-varnish
Если вам необходимо динамически кэшировать контент на основе файла cookie, вы можете сделать это с помощью vcl_hash: https://www.varnish-cache.org/trac/wiki/VCLExampleCacheCookies Это, конечно, снижает вашу посещаемость, поэтому гораздо лучше передать такую функциональность JavaScript для обработки и указать Varnish не кэшировать определенные конечные точки: например,
// don't cache this endpoint, this content changes based on the referrer
if (req.url ~ '/ajax/get_referrer/') { return (pass); }
Единственная часть, которую я не понимаю в вашем вопросе, была:
Cookie также удаляется, поэтому в следующий раз, когда пользователь возвращает страницу, проверяет, существует ли cookie, если да, выбирает отображение правильного кода конверсии в HTML.
Пока внутреннему серверу не нужно видеть cookie или устанавливать cookie, то есть, пока JavaScript отвечает за работу с DOM, вы должны быть в ясности. Обратите внимание, что если «источник / реферер» для каждого пользователя разный, вам также следует указать Varnish не кэшировать какие-либо конечные точки, используемые для получения необходимых данных.
Вы также должны отметить, что вы должны кешировать только запросы GET и HEAD в Varnish. Если ваш поиск или JavaScript использует POST или любой другой тип запроса, их не следует кэшировать.
Однозначно рекомендую делать все на сервере разработки. Вам нужно будет учитывать множество других факторов, таких как доставка PDF-файлов / видео / аудио (также называемых конвейерными запросами), игнорирование страниц и многие другие особенности, уникальные для вашей ситуации.