Время ожидания веб-сайта Google Cloud Run истекает, когда длина контента составляет от 4013 до 8092 символов. Что здесь происходит?

Эта проблема возникает в файлах чистого PHP, обслуживаемых Nginx и PHP-FPM. Я наткнулся на эту проблему при разработке своего веб-сайта с использованием Symfony, но для этого проблемный диапазон длины контента составляет 3702-15965 (интересно, почему он отличается от ванильного PHP).

Что я пробовал до сих пор:

  • Время ожидания составляет 15 секунд, но я попытался увеличить его до 300 секунд, и время ожидания все еще истекает. Так что я предполагаю, что это бесконечная петля.
  • Это не похоже на то, что это связано с ресурсами, потому что оно работает, даже если длина контента составляет 5 миллионов символов.
  • Создал различные тесты с разными символами, чтобы увидеть, могу ли я внести изменения в проблемный диапазон длины контента. Ответ - нет, диапазон оставался одинаковым для всех моих тестов.
  • Я пробовал отключать gzip. Это не изменило диапазон длины, но изменился отклик. Ответ с включенным Gzip: тайм-аут восходящего запроса | Ответ отключен Gzip: полностью пусто

Примечания:

  • Эта проблема не существует на моем локальном хосте.
  • Страница редко открывается нормально. Я не могу воспроизвести это последовательно.
  • В журналах Nginx, PHP или GCR нет никаких ошибок, кроме строк с превышением времени ожидания запроса.

Любая помощь приветствуется. Спасибо.


nginx php google-cloud-run fastcgi fpm
person Taylan    schedule 04.08.2020    source источник

Ответы (2)


arrow_upward
3
arrow_downward

Как ни странно, я решил проблему, когда писал вопрос. Добавление fastcgi_buffering off; в конфигурацию Nginx устраняет проблему.

Но я до сих пор не понимаю, в чем была проблема и почему ее исправило отключение буферизации. Поэтому, если кто-нибудь может это объяснить, я не против отметить этот ответ как решение.

person Taylan    schedule 04.08.2020
comment
Как ни странно, совсем недавно я столкнулся с чем-то подобным. Оказалось, что я отправлял больше данных, чем могло поместиться в буфере fastcgi_buffer_size (мой ответ был 50 КБ). Увеличение fastcgi_buffer_size (вместе с fastcgi_buffers и fastcgi_busy_buffers_size) позволило мне сохранить буферизацию и заставить все работать. - person garbetjie; 16.03.2021

arrow_upward
1
arrow_downward

Это относится к nginx, а не к Cloud Run. Когда nginx начинает получать ответ от бэкэнда FastGCI, он буферизует ответ заголовка в памяти. Если ответ слишком велик для памяти, его часть можно сохранить во временном файле на диске, который управляется другими переменными, как описано здесь. При отключении fastcgi_buffering ответ передается клиенту синхронно по мере его получения. Дополнительную информацию можно найти в этих статьях[1][2][3].

[1] восходящий поток отправил слишком большой заголовок при чтении заголовок ответа от восходящего потока

[2] Вверх по течению Nginx отправлено слишком много заголовок при чтении заголовка ответа из восходящего потока

[3] https://gist.github.com/magnetikonline/11312172#determine-fastcgi-response-sizes

person MaryM    schedule 07.08.2020
comment
Спасибо за ссылки, но я не думаю, что это объясняет, почему тайм-аут происходит только, если содержимое составляет от 4013 до 8092 символов (или от 3702 до 15965 при использовании Symfony). - person Taylan; 08.08.2020