Что такое сессии в битрикс
Перейти к содержимому

Что такое сессии в битрикс

  • автор:

Работа с сессиями

Для включения хранения сессий в 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);

либо в случае использования unix-socket:

define('BX_SECURITY_SESSION_MEMCACHE_HOST', 'unix://path/to/memcached.sock'); define('BX_SECURITY_SESSION_MEMCACHE_PORT', 0);

Не блокирующие сессии

Подходит для AJAX. После этого сессия читается из memcached или БД не ожидая получения блокировки:

define('BX_SECURITY_SESSION_READONLY', true);

Виртуальные сессии

Подходит для REST: сессия создается в памяти, не ждет блокировок и не сохраняется.

define('BX_SECURITY_SESSION_VIRTUAL', true);

Работа с сессиями

Для изменения времени хранения сессий добавьте в .htaccess следующие директивы:

 # Директория хранения файлов сессий для сайта #php_value session.save_path /var/www/ИМЯ_АККАУНТА/data/mod-tmp # Установите максимальное время жизни сессии в секундах. 3600 - 1 час. php_value session.gc_maxlifetime 3600 # Установите время жизни cookie, которая сохраняет идентификатор сессии в браузере пользователя. php_value session.cookie_lifetime 3600 # Для удаления сессий, если в phpinfo(); прописано session.gc_divisor 0 php_value session.gc_probability 100 php_value session.gc_divisor 1
  • Битрикс хостинг
  • VPS / VDS сервер
  • Выделенный сервер
  • Подарки за отзыв
  • Отзывы клиентов
  • Партнерская программа
  • База знаний
  • Для правообладателей

Бесплатно по России

Для звонков из Москвы

Мы используем файлы cookie. Продолжая использовать сайт, вы соглашаетесь с политикой использования cookie файлов. Принять

Проблемы с авторизацией после переноса сайта на другой сервер

Достаточно часто после переноса сайта на CMS 1с-Битрикс / Bitrix с одного хостинга на другой или со старого сервера на новый администраторы сайта сталкиваются с проблемами:

  • При попытке авторизоваться в админ-панели снова перекидывает на форму авторизации
  • Добавление товаров в корзину не срабатывает
  • Заказы на сайте не оформляются
  • В оформлении заказа или других формах появляется ошибка «Ваша сессия истекла. Пожалуйста, перезагрузите страницу»

Как исправить данную проблему?

Данный способ сработает если у вас один сайт по многосайтовости и проблемы описанные выше не воспроизводятся в режиме инкогнито.

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

  1. Переходим в административную панель. Переходим в Настройки > Настройки продукта > Сайты > Список сайтов

Проверяем что у вас один сайт по многосайтовости, открываем его

Проверяем, что сессии хранятся в файлах, значение блока session должно быть равно:

'session' => array ( 'value' => array ( 'mode' => 'default', ), 'readonly' => true, ),
setcookie("PHPSESSID", "", 777, '/', '.site.ru');

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

Блокировки сессий в PHP и их отладка

Буквально несколько дней назад на сайте 1С-Битрикс была опубликована статья Николая Рыжонина о возможностях сократить случаи блокировки сессий для долгих обработок запросов. Мы же в своей статье решили в целом пройтись подробнее — почему эти блокировки происходят, почему PHP-процессы «залипают» на инициализации сессий — session_start() — и как с этим бороться.

Время от времени у наших клиентов в процессе отладки запросов, которые долго выполняются, возникает вопрос — почему сессии начинают долго работать? Выглядит проблема примерно так — неожиданно пользователь, пытаясь открывать новые страницы на сайте, не может дождаться их открытия, а если пользователь генерирует большое число таких запросов, это происходит уже у всех посетителей сайта. Apache/PHP-FPM забиваются процессами, ожидающими снятия блокировки с файла сессий, и часто — помогает только перезапуск этих сервисов.

Для того, чтобы разобраться, в чем же причина таких блокировок и как с ними бороться, давайте разберемся, как в PHP организована работа сессий.

Стандартный обработчик сессий в PHP реализует их хранение в файлах путем хранения сериализованного содержимого массива $_SESSION в файле в директории, заданной переменной session.save_path. При старте сессии функцией session_start PHP либо создает и открывает, либо повторно открывает файл сессии. При этом PHP выставляет глобальную блокировку на чтение этого файла на время работы с ним. Сделано это преднамеренно — в противном случае в условиях многопоточности несколько скриптов могут открыть один и тот же файл с сессией, изменить значения ее переменных, а затем закрыть и записать сессию в файл, и таким образом данные одного из скриптов будут утеряны.
Объяснить это можно простым примером: пусть есть скрипты 1.php и 2.php и некая сессия в которой уже выставлены следующие переменные:

$_SESSION['aaa']='111'; $_SESSION['bbb']='222'; $_SESSION['ccc']='333';

1.php:

2.php:

Если бы в PHP не была реализована блокировка сессий, а скрипты выполнились бы одновременно, результаты выполнения работы скрипта 1.php не были бы сохранены в сессии.

Все это в принципе приемлемо, до той поры, пока скрипты выполняются несколько сотен миллисекунд (что типично для веба), однако активное использование AJAX-а, активная разработка, сложные внутренние портальные системы создают большой риск для длительной блокировки сессий, источник которой приходится довольно нетривиально ловить.

Для примера — довольно часто мы видим, как некие сложные процессы, выполнение которых занимает длительное время, реализуют через AJAX-запрос. Пользователь заходит на страницу, где запускает, например, процесс импорта данных из внешнего сервиса. Импорт происходит в скрипте, через AJAX-запрос. Пока импорт происходит, пользователь может открыть и другие страницы. Если вдруг работа внешнего сервиса замедляется, а скрипт, занимающийся импортом использует сессии — файл сессий останется заблокированным на время выполнения этого скрипта. Соответственно ни одна страница сайта для этого пользователя не будет открыта до завершения его работы. Скрипт выполняется десятки секунд? Все это время сайт будет полностью недоступен для пользователя.

Ловить подобную проблему, если она начинает происходить массово, очень сложно. Если мы решим просто отследить, где висят запросы пользователя — большая часть запросов окажется висящими в состоянии session_start() — раздраженные пользователи пытаются снова и снова открыть недоступные страницы. Для того, чтобы ловить подобныю проблемы, мы рекомендуем использовать профилирующий модуль XHProf от фейсбука с последующей фильтрацией результатов его работы. XHProf сохраняет результаты работы в файл с сериализованным массивом статистики, который потом сам же использует для профилировки. Таким образом мы получаем набор файлов с результатами выполнения каждого запроса пользователя. Для того чтобы выбрать нужные нам результаты, необходимо открыть каждый файл и проверить, какое время выполнения занимала функция session_start() — нас интересуют только те, где выполнения скрипта было долгим, а выполнение этой функции — коротким, те самые скрипты, которые привели к блокировке. Мы для фильтрации используем следующий скрипт:

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *