У меня высокое время выполнения HTTP-запроса (например, 42 КБ за 13 секунд).
Я использую haproxy для балансировки нагрузки трафика. Статические файлы размещаются на сервере lighttpd за ускорителем лака. Итак ... его следует подавать со скоростью ниже скорости света: P
http://img580.imageshack.us/g/34411388.png/
Длинный поиск DNS: pic1
Долгое получение: pic2
Имитационная загрузка: pic3
Я использую googledNS. Сервера находятся в США. Сначала я добавил IP-адреса в / etc / hosts, чтобы пропустить DNS-запрос. Во-вторых, я перенес статику на отдельную машину, опуская haproxy. Таким образом он соединяется напрямую с лаком. Трафик небольшой, потому что это только разработка, но бывает и в продакшене.
http://img580.imageshack.us/g/34411388.png/
После изменений: рис4
Немного лучше, но все еще медленно ...
Прежде всего, вы должны проверить, откуда Varnish обслуживает изображение. Кэширует изображение или каждый раз использует бэкэнд?
Вы можете проверить это разными способами:
-p vcl_trace=true
если у меня хорошо работает память.varnishlog
чтобы посмотреть какой-то запрос к изображению и посмотреть, что происходит (если он обслуживается из кеша и т. д.). Вы должны использовать это, если вы установите vcl_trace
.Как это:
sub vcl_deliver {
if (obj.hits > 0) {
set resp.http.X-Cache = "HIT";
unset resp.http.cookie;
} else {
set resp.http.X-Cache = "MISS";
}
}
Он будет добавлять заголовок X-cache к каждому запросу, который обслуживает Varnish. После проверки правильности кеширования varnish можно поискать причину, по которой нам требуется много времени для ответа, но я полагаю, что наблюдение за запросами в трассировке даст вам некоторые подсказки.
Вы можете быть сбиты Раздутие буфера.