Интерпретация времени обслуживания в стойке - PullRequest
Новая
       27

Интерпретация времени обслуживания в стойке

0 голосов
/ 11 июня 2018

В приложении Rails я использую rack-timeout, установленный для тайм-аута запросов, занимающих более 30 секунд.

Как ни странно, бывают ситуации, когда rack-timeout поступает очень поздно и общее время обслуживаниязапрос может закончиться до 7-30 минут.

Вот 3 примера, иллюстрирующих эту странную ситуацию:

enter image description here enter image description here enter image description here

Вот мой стек промежуточного программного обеспечения: 

use Raven::Rack
use HireFire::Middleware
use ActionDispatch::SSL
use Rack::Sendfile
use HeaderDelete
use ActionDispatch::Static
use #<ActiveSupport::Cache::Strategy::LocalCache::Middleware:0x0000000002d643e8>
use Rack::Timeout
use Rack::Runtime
use Rack::MethodOverride
use ActionDispatch::RequestId
use LoggingMiddleware
use Rails::Rack::Logger
use Chewy::Railtie::RequestStrategy
use ActionDispatch::ShowExceptions
use ActionDispatch::DebugExceptions
...

Учитывая, что rack-timeout расположен в начале стека, как интерпретировать, что некоторые запросы идутдалеко за их пределами?

Я думаю, что это может быть связано с таймаутами во время блоков ввода-вывода (подробности здесь ), хотя это не объясняет, почему пришел первый журнал (state=ready) из rack-timeoutЧерез 27 минут после H12 от маршрутизатора Heroku (примеры 1 и 3 выше)?

Может быть проблема с установкой таймаута обслуживания rack-timeout на 30 секунд (аналогично маршрутизатору Heroku)?

Спасибоза любые идеи!

...