Содержание

Как устроены сессии в PHP, как реализован данный механизм в MODX Revolution и как его можно улучшить

Работая над оптимизацией сайта проекта Лектория, я всегда ищу узкие места, которые в перспективе могут привести к существенным проблемам и стараюсь их в максимально короткие сроки закрывать. Одним из таких вопросов, с которыми я недавно столкнулся, оказался вопрос работы стандартного механизма обработки сессий в MODX.

}

8 минут на прочтение

Теги по теме:

  • Backend
  • MODX

Как я начал ковыряться в этом вопросе

Меня зовут Артем Зернов. Я веб-разработчик, занимаюсь развитием проекта Лектория, а также веду свой youtube-канал OpenModx, а еще у меня есть веб-студия OpenColour, в которой мы создаем сайты, в основном на MODX Revolution.

В процессе своей деятельности в нашей команде мы создали не одну сотню сайтов, и в процессе их обслуживания я замечал, что некоторые, наиболее посещаемые сайты начинали тормозить. Причиной тому была таблица modx_session, о которой мы поговорим позже. Столкнувшись с этой проблемой, я начал разбираться, как устроен механизм сессий в PHP и MODX в частности. И вот буквально сегодня я вновь вернулся к этому вопросу, анализируя поведение сайта Лектории. Спешу поделиться своими наблюдениями и идеями.

Как устроены сессии в PHP по-умолчанию

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

PHPSESSID), то сервер устанавливает вам куки и теперь сервер знает, какая сессия должна быть ассоциирована с вашим визитом.

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

Пока у вас есть в куки идентификатор сессии, сервер знает, кто вы и может показывать вам какие-либо ваши данные, хранимые в сессии.

По-умолчанию, в php есть встроенные функции session_start

, session_write_close и прочие функции с префиксом session_. Полный набор функций можно посмотреть по ссылке:

https://www.php.net/manual/ru/ref.session.php

Также есть глобальный массив $_SESSION, в который вы можете записывать что угодно. MODX также записывает в него свои служебные данные.

Пока сессия открыта и пока не вызван метод session_write_close, все манипуляции с данными в $_SESSION будут сохраняться при переходах между страницами в рамках вашего посещения.

По-умолчанию, в php сессии хранятся в файлах, хранимых во временном каталоге (например /tmp).

Также в дистрибутиве php содержится bash-скрипт sessionclean, который автоматически устанавливается в системные таймеры (можно сказать — это cron) и с периодичностью раз в 30 минут очищает устаревшие сессии, чтобы они не занимали лишнее пространство на диске.

Сессии устаревают по принципу «Если с момента последнего обращения к сессии прошло больше времени, чем укзано в настройке php session.gc_maxlifetime, то считаем ее устаревшей».

Для чего нужны сессии

Сессии — это временные хранилища, связанные с конкретным посетителем, а точнее с браузером. В сессии хранятся данные, потеря которых не несет существенных последствий.

Как и где инициализируются обработчики сессии в MODX

Прежде, чем сказать о том, как это происходит в MODX, важно сказать, что php предусматривает переопределение стандартных механизмов работы с сессиями. Это делается при помощи встроенной в php функции session_set_save_handler, с помощью которой мы можем переопределить способ чтения, записи и очистки от устаревших сессий (сборки мусора).

В MODX это происходит в методе modX::_initSession.

Стандартный механизм обработки сессий в MODX реализован в классе

modSessionHandler. И, как вы наверняка догадались, сессии MODX хранятся в базе данных, а точнее в таблице modx_session. Там хранятся ID сессии (это как раз то, что хранится в куки в переменной PHPSESSID), время последнего доступа к ним и, собственно, сериализованный массив $_SESSION.

Сборщик мусора и настройки gc_probability и gc_divisor

В php механизм очистки от устаревших сессий запускается в соответствии с настройками php.ini session.gc_probability и session.gc_divisor. Очистка происходит session.gc_probability раз из session.gc_divisor.

Например, если session.gc_probability = 1, а session.gc_divisor = 100

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

Если ваш сайт посещают часто, то нужно увеличивать параметр session.gc_divisor. Например, ваш сайт посещают 1000 раз в сутки (речь идет именно об обращении к страницам, которые может делать хоть один и тот же пользователь), тогда при соотношении session.gc_probability/session.gc_divisor 1/1000 хотя бы один раз в сутки у вас будет запускаться механизм очистки от устаревших сессий.

Garbage collector

В переводе с английского означает «сборщик мусора». Сокращенно gc. Универсальное понятие, используемое в разных языках программирования, означающее механизм очистки от устаревших данных.

Как вы понимаете, механизм очистки от устаревших сессий можно запустить и самостоятельно (выше мы говорили о скрипте sessionclean). В Ubuntu этот механизм запускается каждые 30 минут. За другие ОС не скажу.

В MODX процедура очистки от устаревших сессий происходит в методе modSessionHandler::gc.

И тут стоит отметить, что механизм очистки сессии в скрипте sessionclean, запускаемый каждые 30 минут, не будет очищать сессии MODX, так как он ничего не знает о том, что MODX переопределяет стандартные механизмы в классе modSessionHandler. Поэтому, если вы хотите очищать сессии modx вручную, необходимо написать самостоятельно скрипт. Но смысла в этом большого нет, кроме случая, описанного в конце этой статьи, так как очистка сессий будет происходить согласно вашим настройка session.gc_probability и session.gc_divisor.

Время жизни куки и сессий

В настройках php, в php.ini есть настройка

session.gc_maxlifetime, которая определяет время с момента последнего обращения к сессии, после которого сессия считается устаревшей и будет удалена во время следующей очистки сессий (сборке мусора) и session.cookie_lifetime, которая определяет время жизни куки PHPSESSID в вашем браузере.

Стоит отметить, что MODX переопределяет эти настройки, согласно своим аналогичным системным настройкам session_cookie_lifetime и session_gc_maxlifetime, поэтому в первую очередь смотрите именно в системные настройки вашего сайта на MODX.

Логично, что выставлять cookie_lifetime больше, чем gc_maxlifetime смысла нет.

Почему моя таблица modx_session весит 2Гб?

Впервые с вопросом, как работают сессии в MODX я столкнулся, когда начал замечать, что если я давно не занимался каким-либо сайтом, то на сервер, где он расположен, таблица modx_session становится непомерно огромной, что порой это приводит к замедлению работы сайта из-за долгой выборки сессии из этой таблицы.

Стоит понимать, что сессия создается независимо от того, является ли пользователь авторизованным или нет. Как только на ваш сайт попадает новый пользователь, у вас автоматически появляется новая запись в таблице modx_session. А если он это делает еще и с нескольких устройств, то количество записей будет равно количеству устройств. Правда, это можно исправить, выключив системную настройку anonymous_sessions. Но, если у вас интернет-магазин, то выключать ее нельзя, иначе у неавторизованных пользователей не будет работать, например, корзина.

Учитывая все вышеописанное, такое происходит только потому, что данная таблица не очищается от устаревших сессий.

Как это можно решить?

  1. Проверить параметр session.gc_probability на сервере, он должен быть больше 0. Если он равен 0, значит механизм очистки от старых сессий не запускается никогда.
  2. Проверить, насколько часто запускается механизм очистки сессий. Если, к примеру, параметр session.gc_divisor очень большой, то возможно, при вашей посещаемости, очистка от устаревших сессий происходит 1 раз в год или еще реже.
  3. Проверить время жизни сессий (настройка MODX session_gc_maxlifetime). Если она очень большая, например 1 год, то, очевидно, в течение года сессия будет оставаться живой.
    А если, при этом, параметр session_cookie_lifetime значительно меньше этого значения, то на одного пользователя потенциально будет создаваться больше, чем одна сессия, что является излишним.
  4. Если возможности изменить настройку сессий session.gc_probability или session.gc_divisor у вас нет, то есть смысл написать cron-скрипт, о котором я писал выше.

Доходило до такого, что таблица modx_session ввиду отсутствия корректных настроек сессии и обслуживания сайта, разрасталась до нескольких гигабайт

Как можно улучшить стандартный механизм работы с сессиями в MODX

Ко мне пришла в голову идея расширить стандартный класс modSessionHandler, заставив его работать с другой таблицей, которая представляет собой копию modx_session, но где мы можем добавить свои столбцы, например столбец anonymous, столбец user_id и прочие полезные столбцы, по которым мы могли бы делать выборку сессий.

После таких манипуляций, необходимо указать системную настройку session_handler_class, вставив туда название нашего кастомного класса для работы с сессиями (при этом, к сожалению, нет настройки для указания пути к классу, поэтому файл придется класть в системный каталог MODX, туда же, где лежит файл modsessionhandler.class.php).

Какие это может дать преимущества

  1. При очистке сессий мы можем делать разные условия для времени жизни сессии авторизованных пользователей и анонимных. Например, сессиий анонимных пользователей действительны в течение одних суток, а авторизованных — в течение 7 дней.
  2. При авторизации одного и того же пользователя с разных устройств, мы могли бы удалять его другую сессию, предотвращая тем самым одновременный вход с разных устройств (если такое предусмотрено логикой вашего сайта).
  3. При авторизации одного и того же пользователя с разных IP мы могли бы сообщать о подозрительной активности.
  4. Можно расширить эту таблицу прочими полезными столбцами, которые мы могли бы использовать себе во благо и расширять сайт дополнительным функционалом.

Заключение

Спасибо за внимание! Надеюсь, статья была интересной и вдохновит кого-то из читателей на новые идеи.

Не забывайте подписываться на мой youtube-канал: OpenModx!

Поделитесь с друзьями в социальных сетях

Другие статьи

  • История моего знакомства с MODx Revolution

    #Backend

    #Frontend

    #MODX

  • Очереди в Laravel или почему ваш сайт тормозит

    #Backend

    #Laravel

  • Актуальные frontend-технологии, которые должен знать каждый разработчик на фрилансе

    #Frontend

    #Работа в IT

  • MODx FormIt. Создание форм с произвольной логикой

    #Backend

    #Frontend

    #MODX

Узнавайте первым о новых курсах и лекциях

Email

Темы

Backend

Frontend

Веб-дизайн

e-Маркетинг

MODX

Laravel

Работа в IT

Vue

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

Сессии в куках, время жизни | PHPClub

BigHarry
Новичок

Опции конфигурации сеанса
Имя По умолчанию Сменный Список изменений
session.save_path «» PHP_INI_ALL  
сеанс.имя «PHPSESSID» PHP_INI_ALL  
session.save_handler «файлы» PHP_INI_ALL  
сеанс.auto_start «0» PHP_INI_PERDIR  
session.gc_probability «1» PHP_INI_ALL  
session. gc_divisor «100» PHP_INI_ALL  
session.gc_maxlifetime «1440» PHP_INI_ALL  
сеанс.serialize_handler «php» PHP_INI_ALL  
session.cookie_lifetime «0» PHP_INI_ALL  
session.cookie_path «/» PHP_INI_ALL  
session.cookie_domain «» PHP_INI_ALL  
session.cookie_secure «» PHP_INI_ALL  
session.cookie_httponly «» PHP_INI_ALL Доступно с версии PHP 5.2.0.
session.cookie_samesite «» PHP_INI_ALL Доступно с версии PHP 7. 3.0.
сеанс.use_strict_mode «0» PHP_INI_ALL Доступно с версии PHP 5.5.2.
session.use_cookies «1» PHP_INI_ALL  
session.use_only_cookies «1» PHP_INI_ALL  
session.referer_check «» PHP_INI_ALL  
session.cache_limiter «нокэш» PHP_INI_ALL  
session.cache_expire «180» PHP_INI_ALL  
session.use_trans_sid «0» PHP_INI_ALL  
session.trans_sid_tags «a=href,area=href,frame=src,form=» PHP_INI_ALL Доступно с версии PHP 7. 1.0.
сеанс.trans_sid_hosts $_SERVER[‘HTTP_HOST’] PHP_INI_ALL Доступно с версии PHP 7.1.0.
session.sid_length «32» PHP_INI_ALL Доступно с версии PHP 7.1.0.
session.sid_bits_per_character «4» PHP_INI_ALL Доступно с версии PHP 7.1.0.
session.upload_progress.enabled «1» PHP_INI_PERDIR Доступно с версии PHP 5.4.0.
session.upload_progress.cleanup «1» PHP_INI_PERDIR Доступно с версии PHP 5.4.0.
session.upload_progress.prefix «upload_progress_» PHP_INI_PERDIR Доступно с версии PHP 5.4.0.
session.upload_progress. name «PHP_SESSION_UPLOAD_PROGRESS» PHP_INI_PERDIR Доступно с версии PHP 5.4.0.
session.upload_progress.freq «1%» PHP_INI_PERDIR Доступно с версии PHP 5.4.0.
session.upload_progress.min_freq «1» PHP_INI_PERDIR Доступно с версии PHP 5.4.0.
session.lazy_write «1» PHP_INI_ALL Доступно с версии PHP 7.0.0.
url_rewriter.tags «a=href,area=href,frame=src,form=» PHP_INI_ALL Начиная с PHP 7.1.0, этот INI больше не используется сеансом.
session.hash_function «0» PHP_INI_ALL Удалено в PHP 7.1.0.
session.hash_bits_per_character «4» PHP_INI_ALL Удалено в PHP 7. 1.0.
session.entropy_file «» PHP_INI_ALL Удалено в PHP 7.1.0.
session.entropy_length «0» PHP_INI_ALL Удалено в PHP 7.1.0
session.bug_compat_42 «1» PHP_INI_ALL Удалено в PHP 5.4.0.
session.bug_compat_warn «1» PHP_INI_ALL Удалено в PHP 5.4.0.