производительность — Почему PHP Symfony sfSessionStorage :: initialize иногда занимает очень (очень) много времени?

Question

производительность — Почему PHP Symfony sfSessionStorage :: initialize иногда занимает очень (очень) много времени?

У нас есть разные PHP-приложения, как в symfony 1.4, так и в symfony 2, и все они в какой-то момент имеют запросы, для которых sfSessionStorage :: initialize занимает очень очень много времени.

Я говорю о нескольких минут загрузить. Возьмите этот новый реликтовый след, например:

Здесь вы можете увидеть sfSessionStorage :: initialize взял 185 секунд. Мы отлаживали это уже несколько дней, но пока безуспешно. Мы изучили настройки GC, событие попыталось смонтировать, где сеансы хранятся в файловой системе в RamDisk, без эффекта.

Что может быть причиной этого? Вы когда-нибудь сталкивались с той же проблемой? Любая помощь с благодарностью, спасибо!

5

io performance php session symfony

Решение

Другие решения

Не уверен, что это поможет, но проверьте.

Если вы обрабатываете сеанс вручную, вы должны отключить сеанс, в frontend/config/factories.yml

all:
storage:
class: sfSessionStorage
param:
auto_start: false

Тебе следует увидеть Деактивация неиспользуемых функций для увеличения производительности.

Просто еще одно предположение:

Сессии зависят от файлов. Так что проверьте, что ваша система способна открыть столько файлов, сколько необходимо для сеансов. Или есть какие-либо проблемы для создания файлов.

2

Благодаря комментарию @SomeHelpingDude, указывающему на эту тему: https://forums.powweb.com/showthread.php?t=77977, была упомянута возможность реализации собственного обработчика сессии (http://www.php.net/manual/en/function.session-set-save-handler.php).

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

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

Я все еще ломаю голову над тем, почему рамдиск не исправил это в первую очередь, поэтому, если кто-то сможет это объяснить, я изменю принятый ответ. Спасибо!

1

Источник

Accepted Answer

Трассирование может пролить свет на то, что происходит.

Предполагая, что вы не можете воспроизвести проблему с cli, я бы порекомендовал ограничить количество процессов до 1 (MaxRequestWorkers для mod_php и max_children для php_fpm), присоединить strace к процессу и проверить, где он зависает.

Например, в случае php_fpm:

открыть /etc/php5/fpm/pool.d/www.conf и проверьте настройки
```
pm = static
pm.max_children = 1
```
перезапустите php_fpm и nginx
grep aux | php узнать идентификатор процесса
sudo strace -p с последующим идентификатором процесса
попытаться воспроизвести проблему

Если он останется в течение нескольких минут с одним системным вызовом, вы четко увидите блокировщик прямо в стандартный вывод strace. Если нет единого блокировщика, а есть длинный цикл повторных системных вызовов, вам, вероятно, потребуется записать его в файл и проанализировать позже. Например. sudo strace -p {pid} | tee /tmp/strace.log,

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

3