Оптимизация загруженного сайта с Varnish и большим количеством оперативной памяти

Что именно это число посетителей 85000/ день? Уникальные посетители, общее количество посещений HTTP, что-то еще?

Varnish должен обрабатывать тысячи обращений в секунду с небольшим использованием ЦП и памяти, если запросы могут обслуживаться из кэша. Особенно, когда Slashdotted, так как большинство людей будут искать точно такой же контент. Это требует предварительной настройки, хотя. По умолчанию он довольно консервативный, так как мало что знает о контенте, который проходит через него. Он принимает решения на основе заголовков, которые он видит, и простого набора правил. Например, по умолчанию Varnish кэширует объекты в течение 2 минут, но только в том случае, если в запросе отсутствуют файлы cookie, а TTL объекта>0, и... и т. Д. Проверьте VCL по умолчанию (в частности, vcl_recv и vcl_fetch), чтобы определить логика по умолчанию, и убедитесь, что вы понимаете это.

Таким образом, один файл cookie Google Analytics, установленный в вашем домене, приводит к тому, что все запросы передаются бэкэнду, даже если файлы cookie GA обрабатываются не вашим бэкэнд-сервером, а JavaScript-кодом Google. Приложение WordPress устанавливает все виды файлов cookie, большинство из которых применимы только к динамическому контенту, которые возвращаются браузером при каждом отдельном запросе. Если ваша страница содержит 49 статических ресурсов и 1 динамическую страницу, это означает, что ни один из этих статических ресурсов не будет кэширован, поскольку запросы содержат файл cookie, который вас не интересует. Только cookie в динамическом запросе должен пройти. Такая ошибка по существу отключает Varnish. Кроме того, важны различные заголовки HTTP для управления кэшем (и связанные с ними), которые возвращает ваш код. Если ваше приложение утверждает, что объект, который Varnish извлекает из серверной части, уже истек, например, с заголовком Expires в прошлом, Varnish не будет кэшировать этот объект.

Другими словами, вам нужно настроить приложение так, чтобы оно выдавало правильные заголовки, чтобы клиенты (как Varnish, так и браузер) могли кэшировать возвращаемый контент. Все, что вы не можете исправить в своем приложении, вы можете переопределить в VCL Varnish.

Например, вот мой код для удаления различных файлов cookie отслеживания на стороне клиента с сервера. Это принадлежит в vcl_recv:

# Remove tracking cookies. The server doesn't need to see them.
if (req.http.Cookie) {
    # Remove has_js and Google Analytics __* cookies.
    set req.http.Cookie = regsuball(req.http.Cookie, "(^|;\s*)(_[_a-z]+|has_js|sifrFetch)=[^;]*", "");
    # Remove a ";" prefix, if present.
    set req.http.Cookie = regsub(req.http.Cookie, "^;\s*", "");
    # Remove cookie header if empty
    if (req.http.Cookie == "") {
        remove req.http.Cookie;
    }
}

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

if  ( req.url ~ "^/cms/cms_files/(?:css|img|js)/" ||  #CMS1
      req.url ~ "^/site_files/(?:css|img|imgc|js|swf|uploads|xml/.+\.xml$)" ||  #CMS1
      req.url ~ "^/(?:images|stylesheets|javascripts|swf|site_files/js_libs|site/image|favicon\.ico$|robots\.txt$)" ||  #CMS2
      ( req.http.host ~ "(?:shop\.example\.com|www\.example\.nl)"  &&  #Magento
        req.url ~  "^/(?:404|js|media|skin|favicon\.ico$)" ) || #Magento
) {
    unset req.http.cookie;
}

Я использую похожий раздел в vcl_fetch, с unset beresp.http.cookie; вместо этого, чтобы запретить бэкэнду устанавливать куки на пути, которые я не хочу.

Вы можете добавить несколько заголовков отладки, которые дают вам информацию о том, как лак обрабатывает запросы. Просмотрите их с помощью Firebug, и вы поймете намного больше о своем приложении. Другим хорошим источником информации является Varnish Book. Например, см.: https://www.varnish-software.com/static/book/VCL_Basics.html

Большая часть нашего динамического контента кешируется в течение 60-х годов, чего достаточно, чтобы отогнать паническое бегство. Если вам требуется какой-то отдельный контент, но большая часть контента на ваших страницах довольно статична, посмотрите на ESI Varnish (edge-side-includes), который позволяет вам указывать разные кеш-TTL для разных частей страницы.

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

Вы правы в том, что:MaxClients x (maximum physical memory per Apache process) = (total memory Apache can use)

Это физическая память, а не виртуальная память, которую вы упомянули. Вверху столбец res показывает физическую память, используемую каждым процессом. Каждый процесс Apache превращается в самые большие скрипты, которые запускает ваш сайт. Ограничьте MaxClients количеством, которое может обработать ваш сервер. Нет смысла принимать запросы, для которых у вас нет ресурсов. Как только вы начинаете обмениваться, вы проиграли. Увеличьте количество процессов (серверов), которые выполняет Apache, поскольку разветвление - это тяжелая операция, которую вы хотите выполнять, когда она уже занята. Строка ServerLimit является избыточной. Либо отключите KeepAlive, либо установите его на 1-2 секунды.

Если вы обслуживаете много статических ресурсов, рассмотрите возможность перехода с mod_php на PHP-FPM. Это делает ваши процессы Apache легкими.