#caching #reverse-proxy #varnish #server-side-includes #edge-side-includes
#кэширование #обратный прокси #varnish #на стороне сервера-включает #edge-side-включает
Вопрос:
Мне интересно, какова производительность модуля ESI в настоящее время? Я прочитал несколько сообщений в Интернете о том, что производительность ESI на varnish на самом деле была медленнее, чем реальная.
Допустим, у меня была страница с более чем 3500 включениями esi, как бы это работало? предназначен ли esi для такого использования?
Комментарии:
1. Я могу придумать способ выяснить! Создайте страницу с 3500 включениями и проведите ее тест, я, например, был бы очень заинтересован в результатах 🙂
2. Я бы с удовольствием это сделал, но я новичок в varnish и думаю, что такой тест должен выполнять профессионал.
3. Зачем вам 3500 включений на одной странице? Просто пытаюсь представить такой вариант использования
4. Я думал о документах в формате json. особенно для больших документов. где можно было бы связать разные «вложенные документы» вместе с esi: includes. допустим, у вас есть документ, который предоставляет вам список сотрудников, но он дает вам только идентификатор сотрудника и ничего больше. Затем с помощью ESI вы могли бы включить в него информацию о сотруднике на основе идентификатора.
5. Я бы, вероятно, включил выборку в виде отдельного запроса к необходимому списку сотрудников вместо того, чтобы выполнять итерацию по каждому из них.
Ответ №1:
Мы используем Varnish и ESI для встраивания вложенных документов в документы JSON. В основном ответ от нашего сервера приложений выглядит следующим образом:
[
<esi:include src="/station/best_of_80s" />,
<esi:include src="/station/herrmerktradio" />,
<esi:include src="/station/bluesclub" />,
<esi:include src="/station/jazzloft" />,
<esi:include src="/station/jahfari" />,
<esi:include src="/station/maximix" />,
<esi:include src="/station/ondalatina" />,
<esi:include src="/station/deepgroove" />,
<esi:include src="/station/germanyfm" />,
<esi:include src="/station/alternativeworld" />
]
Включенные ресурсы сами по себе являются полными и действительными ответами JSON. Полный список всех станций составляет около 1070. Итак, когда кэш не работает и первым запросом является полный список станций, varnish выдает 1000 запросов на наш серверный сервер. Когда кэш горячий, ab выглядит следующим образом:
$ ab -c 100 -n 1000 http://127.0.0.1/stations
[...]
Document Path: /stations
Document Length: 2207910 bytes
Concurrency Level: 100
Time taken for tests: 10.075 seconds
Complete requests: 1000
Failed requests: 0
Write errors: 0
Total transferred: 2208412000 bytes
HTML transferred: 2207910000 bytes
Requests per second: 99.26 [#/sec] (mean)
Time per request: 1007.470 [ms] (mean)
Time per request: 10.075 [ms] (mean, across all concurrent requests)
Transfer rate: 214066.18 [Kbytes/sec] received
Connection Times (ms)
min mean[ /-sd] median max
Connect: 1 11 7.3 9 37
Processing: 466 971 97.4 951 1226
Waiting: 0 20 16.6 12 86
Total: 471 982 98.0 960 1230
Percentage of the requests served within a certain time (ms)
50% 960
66% 985
75% 986
80% 988
90% 1141
95% 1163
98% 1221
99% 1229
100% 1230 (longest request)
$
100 записей в секунду выглядят не очень хорошо, но учитывайте размер документа. 214066 Кбайт / сек хорошо перенасыщают интерфейс в 1 Гбит.
Один запрос с разогретым кэшем ab (ab -c 1 -n 1 …) показывает 83 мс в секунду.
Сам серверный сервер основан на redis. Мы измеряем среднее время отклика в 0,9 мс [так в оригинале] в NewRelic. После перезапуска Varnish первый запрос с холодным кэшем (ab -c 1 -n 1 …) показывает 3158 мс / сек. Это означает, что для генерации ответа требуется Varnish и нашему бэкэнду около 3 мс на каждый ESI, включая. Это стандартная коробка для пиццы core i7 с 8 ядрами. Я измерил это, находясь при полной загрузке. Таким образом, мы обслуживаем около 150 млн запросов в месяц с частотой посещений 0,9. Эти цифры действительно указывают на то, что ESI-включения разрешаются последовательно.
Что вы должны учитывать при проектировании подобной системы, так это 1) то, что ваш серверный сервер способен принимать нагрузку после перезапуска Varnish, когда кэш не работает, и 2) то, что обычно срок действия ваших ресурсов истекает не сразу. В случае наших станций срок их действия истекает каждый полный час, но мы добавляем случайное значение продолжительностью до 120 секунд в заголовок истечения срока действия.
Надеюсь, это поможет.
Комментарии:
1. Я только что вспомнил, что у нас были проблемы с выпуском Varnish 3.0.0 и более чем 250 включениями ESI. Обязательно используйте версию 3.0.2 или выше.
2. Очень хороший показатель времени истечения, ваше решение здесь очень умное. Определенно это кража!
Ответ №2:
Это не из первых рук, но я склонен полагать, что текущая реализация ESI в Varnish сериализует запросы include; т. Е. они не параллельны.
Если это так, то в упомянутом вами случае производительность действительно снизилась бы.
Я постараюсь попросить прокомментировать кого-нибудь с опытом из первых рук.
Комментарии:
1. На самом деле это правда, это известный недостаток в реализации ESI в varnish
2. Я могу подтвердить это на практическом тестировании: с установкой php Symfony 2.6: простой главный контроллер / представление, который отображает (с помощью render_esi) два «дочерних» контроллера, каждый из которых имеет паузу «sleep (n)», будет отображать страницы последовательно следующим образом: сначала он отображает родительский вид. Затем он отображает первый тег esi: include. Затем он отображает второй. В моем примере только родительская страница имеет общий-max-возраст 600, и, как и ожидалось, два дочерних элемента никогда не кэшируются. Я ожидал, что они будут извлекаться одновременно, но на самом деле они извлекаются последовательно.
3. cernio — какая версия varnish?
Ответ №3:
Параллельные запросы ESI доступны в ** коммерческой ** версии varnish: https://www.varnish-software.com/plus/parallel-esi /. Параллельный характер запросов на фрагменты, по-видимому, ускоряет сборку страницы, состоящей из нескольких фрагментов.
(это был бы комментарий, но у меня недостаточно репутации для этого)