Общие сведения о Varnish: может ли он кэшировать 10 000 статических страниц на сайте?

Во-первых, я использую: APC, W3TC, PHP5, Wordpress 3.8, Apache 2.2 и получаю много "промахов кеша"

Все еще не очень хорошо понимаю Varnish. Вот некоторая статистика, которую я получил от бэкэнда Unixy за несколько минут работы:

client_conn: 3744 client_drop: 0 client_req: 3910 cache_hit: 914 cache_miss: 2347

Я изменил свою память Varnish на 3 ГБ ОЗУ (из 8 всего).

Это нормально, что Varnish кэширует только часто посещаемые страницы? Допустим, у вас есть сайт с 10 000 страниц. Может ли Varnish хранить все эти страницы в кеше или кэширует только определенное количество часто запрашиваемых страниц?

Итак, мой вопрос действительно в том, как я могу улучшить Varnish, чтобы кэшировать больше страниц и хранить их в кеше в течение длительного времени (в основном статические страницы, которые не нужно много обновлять)

varnish

3 ГБ должно быть достаточно, серьезно. Если вы действительно достигнете предела, у вас не будет промаха кеша, но потеря кеша, который в вашем случае: 0

Так что память, наверное, не эта проблема.

Использование памяти varnish довольно простое, для работы используется не так много памяти, и большая часть памяти используется для хранения объектов, объект относится к вашим веб-страницам, поэтому html-страница размером 50 КБ, кэшированная в лаке, будет использовать около 50 КБ в лаке. .

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

вот vcl по умолчанию для вычисления хэша для объекта:

sub vcl_hash {
  hash_data(req.url);
  if (req.http.host) {
    hash_data(req.http.host);
  } else {
    hash_data(server.ip);
  }

  return (hash);
}

Как видите, он основан на полном URL-адресе и хосте. Существует querystring-vmod для сортировки и / или удаления параметров запроса, чтобы увеличить количество совпадений.

Это может быть хорошим началом, чтобы проверить, не отличается ли ваш объект от varnish (в большинстве случаев это из-за параметров запроса).

Но в вашем случае я действительно подозреваю, что у вас файлы cookie и / или неправильные заголовки управления кешем.

По умолчанию varnish игнорирует все запросы с файлами cookie, увеличивая количество промахов в кеше.

sub vcl_recv {
  // ...

  if (req.http.Authorization || req.http.Cookie) {
    /* Not cacheable by default */

    return (pass);
  }
}

Если вы действительно знаете, что делаете, вы можете удалить файлы cookie из запросов и принудительно кэшировать свой объект, но будьте осторожны, вы можете кэшировать страницу администратора таким образом, которая будет доставлена гостям.

Например, вы можете определить, какой URL-адрес следует кэшировать, и установить Cache-Control: public заголовок и в вашем vcl обнаружите общедоступный Cache-Control заголовок, удалите куки и кеш.

Но опять же будьте осторожны.

РЕДАКТИРОВАТЬ: Вас может заинтересовать эта статья: Лак и Wordpress в документации Varnish

В дополнение к конфигурации Unixy Varnish я добавил это после исследования различных конфигураций, возможно, некоторые из них избыточны, но мой коэффициент HIT для кеша теперь намного лучше, например 60%, и мне удалось снизить нагрузку на процессор с 3 до 0,10 - 0,50

серверная часть wordpress

if (!(req.url ~ "wp-(login|admin)")) {
                unset req.http.cookie;
        }

другие файлы

  if ( req.url ~ "(?i)\.(png|gif|jpeg|jpg|ico|swf|css|js|html|htm)(\?[a-z0-9]+)?$" ) {

        unset req.http.cookie;
  }

печенье

if (req.http.Cookie) {
    set req.http.Cookie = regsuball(req.http.Cookie, "(^|; ) *__utm.=[^;]+;? *", "\1");

    if (req.http.Cookie == "") {
        remove req.http.Cookie;
    }
}

очистка

if (req.request == "PURGE") {
return (lookup);
}

Также 3 ГБ - это немного перебор, я могу изменить его обратно на 1 или 2 ГБ .. даже с 10 000 страниц или более, но я позволю ему работать в течение 24 часов и посмотреть