Symfony2: прерывистое высокое время отклика/медленное завершение SessionHandlerProxy::read()

Я наблюдаю очень странное поведение компонента диспетчера сеансов Symfony2. В частности, функция SessionHandlerProxy::read() иногда работает очень медленно в моей производственной среде.

Symfony\Component\HttpFoundation\Session\Storage\Proxy\SessionHandlerProxy::read

Я использую Apache2 на Amazon EC2 под управлением Ubuntu с хранилищем сеансов Symfony2 по умолчанию (не Redis или что-то подобное), хотя мне интересно, следует ли мне это делать. У меня установлен NewRelic для отслеживания моих транзакций, который сообщает следующее:

Медленное время отклика

Медленные ответы являются прерывистыми, и я не заметил какой-либо заметной корреляции между запросами в минуту и ​​медленным временем чтения сеанса. Я в тупике, есть идеи, что я могу попробовать?


php response symfony session newrelic
person CaptainStiggz    schedule 24.05.2016    source источник
comment
Как насчет пропускной способности ввода/вывода? Собственный обработчик — это файловый обработчик.   -  person Aleksander Wons    schedule 25.05.2016
comment
Спасибо за ответ. Не уверен, что понимаю, о чем вы спрашиваете. Собственный обработчик сеансов хранит сеансы в локальных файлах? Таким образом, пропускная способность ввода-вывода для большого количества запросов снижается по сравнению с чем-то более быстрым?   -  person CaptainStiggz    schedule 25.05.2016
comment
По умолчанию сеансы в PHP хранятся в файлах. Если вы испытываете ненормальное количество операций ввода-вывода на диске, где хранятся сеансы, это может привести к поведению, которое вы описываете. Стоит проверить.   -  person Aleksander Wons    schedule 25.05.2016
comment
Спасибо, awons, я взглянул на скорость ввода-вывода, она очень низкая в трудные периоды - никогда не превышала 50 кбит / с, должно быть что-то еще.   -  person CaptainStiggz    schedule 26.05.2016
comment
Боюсь, что возможных причин может быть много, и у нас недостаточно информации, чтобы понять, что там происходит :(   -  person Aleksander Wons    schedule 26.05.2016

Ответы (1)


arrow_upward
2
arrow_downward

Я столкнулся с чем-то подобным на проекте. Я определил это, когда мы переключились на Redis для обработки сеанса (мы вернулись к обработчику файловой системы по умолчанию для PHP, проблема все еще возникает с перерывами).

Скорее всего, метод SessionHandlerProxy::read() заблокирован для сеанса, и процесс ожидает разблокировки сеанса.

Блокировка сеанса — это хорошо, поскольку она предотвращает условия гонки в php. Так что, вероятно, происходит то, что другой запрос в настоящее время обращается к сеансу и не освобождает его настолько быстро, насколько это возможно. Решение, которое я нашел благодаря своим навыкам Google fu вызывает обработчик $session->save(), как только вы закончите сеанс, который стажер вызывает session_write_close() (это разблокирует сеанс для следующего запроса).

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

Документация Symfony API для Session:Save()

Вот исходный вопрос о переполнении стека (хотя и 5 лет назад ).

person dbergunder    schedule 03.02.2017