Лак и ESI, как производительность?

Question

Мне интересно, как в настоящее время производительность этого модуля ESI? Я читал некоторые посты в Интернете, что производительность ESI на лаке на самом деле была ниже, чем на самом деле.

Скажем, у меня была страница с более чем 3500 включениями, как бы это работало? ESI предназначен для такого использования?

Answer 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. Поэтому, когда кеш холодный и полный список станций является первым запросом, лак выдает 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 rec / sec выглядит не очень хорошо, но учитывайте размер документа. 214066 Кбайт / с перенасыщает интерфейс 1 Гбит.

Один запрос с теплым кэшем ab (ab -c 1 -n 1 ...) показывает 83 мс / кв.

Сам бэкэнд основан на redis. Мы измеряем среднее время отклика 0,9 мс [sic] в NewRelic. После перезапуска Varnish первый запрос с холодным кэшем (ab -c 1 -n 1 ...) показывает 3158ms / rec. Это означает, что при генерации ответа требуется Varnish и наш бэкэнд около 3 мс на ESI. Это стандартная коробка для пиццы i7 с 8 ядрами. Я измерил это, находясь под полной нагрузкой. Таким образом, мы обслуживаем около 150 млн. В месяц с рейтингом 0,9. Эти цифры действительно указывают на то, что ESI-включения разрешаются в последовательном порядке.

При проектировании системы, подобной этой, вам необходимо учесть следующее: 1) ваш бэкэнд может взять на себя нагрузку после перезапуска Varnish, когда кеш холодный, и 2) что обычно ресурсы не истекают сразу. В случае наших станций они истекают каждый полный час, но мы добавляем случайное значение до 120 секунд в заголовок срока действия.

Надеюсь, это поможет.

Answer 2

Это не из первых рук, но я склонен полагать, что текущие реализации Varnish ESI включают запросы; то есть они не совпадают.

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

Я постараюсь, чтобы кто-то с личным опытом прокомментировал.

Answer 3

Параллельные запросы ESI доступны в ** коммерческой ** версии лака: https://www.varnish -software.com / plus / parallel-esi /. Параллельная природа запросов фрагментов, по-видимому, ускоряет сборку страницы, состоящей из нескольких фрагментов.

(это будет комментарий, но у меня недостаточно репутации, чтобы сделать это)