1. Хранение сессий в memcached
Для включения хранения сессий в memcached необходимо в /bitrix/php_interface/dbconn.php или /local/php_interface/dbconn.php установить следующие константы
define('BX_SECURITY_SESSION_MEMCACHE_HOST', 'localhost'); define('BX_SECURITY_SESSION_MEMCACHE_PORT', 11211); |
define('BX_SECURITY_SESSION_MEMCACHE_HOST', 'unix:///path/to/memcached.sock'); define('BX_SECURITY_SESSION_MEMCACHE_PORT', 0); |
Данный способ хранения сессий дает следующие преимущества:
- нет необходимости следить за количеством старых сессий на нагруженном проекте
- возможность разделять сессии между серверами в кластере
- возможность использовать не ожидающую получения блокировки сессию
- возможность использовать виртуальные сессии
В целом хранение сессий в БД имеет такие же преимущества, но в отличие от хранения сессий в memcached, значительно более медленное. Поэтому рекомендуем использовать хранение сессий в memcached, взамен хранения сессий в БД.
2. Не блокирующие сессии.
Одной из проблем больших проектов с множественными аякс запросами, является частые блокировки хитов одного пользователя на ожидание получения блокировки сессии. Особенно это актуально для КП, где во многих местах прикрепленные к сущностям файлы отдаются пользователю, после проверки прав на php. Поэтому на страницах возможно построение лесенки, из за ожидания получения блокировки сессии. Включить не блокирующую сессию можно установкой константу, до подключения ядра продукта.
define('BX_SECURITY_SESSION_READONLY', true); |
3. Виртуальные сессии.
Не блокирующих сессий, для большинства кейсой достаточно. Но в некоторых ситуациях, когда сессия нам не нужна совсем, использование не блокирующей сессии все таки избыточно. Так как сессия будет создаваться в случае ее отсутствия. В результате при большом количестве не связанных между собой хитов, будет созданно большое количество мусорных сессий. Примером таких хитов, являются хиты реста. Для решения этой проблемы была добавлена "Виртуальная сессия". Суть которой заключается в том, что сессия создается в памяти, не ждет блокировок и не сохраняется. Для ее включения необходимо установить константу, до подключения ядра продукта.
define('BX_SECURITY_SESSION_VIRTUAL', true); |
В качестве небольшого заключения. Если у вас КП, проект с большим количеством ajax запросов или много файлов отдается с проверкой прав (например в блогах, соцсети, форуме) то лучше использовать хранение сессий в memcached средствами ядра.
Можете привести то, что у вас прописано.
Мне интересно, почему в ошибке указан 46575 порт.
Вот они вместе с трассировкой
BX_SECURITY_SESSION_READONLY
блокирует запись в сессию memcached
БЛОКИРУЕТ, а не наоборот
оказывается есть другой
BX_SECURITY_SESSION_MEMCACHE_EXLOCK
который и служит для отмена блокировок на сессию в memcached
/bitrix/php_interface/dbconn.php
т.е. если аякс-страница будет менять сессию с такой константой, ничего в сессии не отразиться?
Подскажите пожалуйста, в чем может быть проблема:
Есть кластер, 2 веб сервера, 3 бд,. доменная авторизация
после включения данной функции
в dbconn.php на обеих серверах
define('BX_SECURITY_SESSION_READONLY', true); - эту константу нельзя ведь ставить на весь портал целиком?
Может подскажите в каких файлах ее можно добавить для КП? т.к. у меня сейчас очень часто блокируется сессия для пользователей портала.
А вы на портале используете memcache для хранения сессий?
Сессии хранятся в БД (только Смена идентификатора сессии - отключена) - в итоге у разных пользователей периодически возникает ошибка "Unable to get session lock within 60 seconds".
Возвращение хранения сессий в файлы не помогает, в логи ошибка уже не пишется, но портал все также подвисает для определенного пользователя, пока не удалишь его сессию.
Чаще всего выполняются запросы от декстоп приложения и запросы к мессенджеру "/bitrix/components/bitrix/im.messenger/im.ajax.php" - поэтому была мысль в этих файлах поставить BX_SECURITY_SESSION_READONLY, но пока не до конца понимаю, на что это может повлиять.
Буду благодарен за совет: в какую сторону смотреть!