[ExtSession] - Расширение стандартных сессий для MODX3

[ExtSession] — Компонент расширяет класс modSession, добавляет следующие поля в родную таблицу сессий.
user_bot - указатель на сессию бота
user_id - идентификатор пользователя
user_ip - ip адрес пользователя
user_agent - user-agent пользователя
дает возможность гибко управлять временем жизни сессии ботов, авторизованных и Не-авторизованных пользователей.
Доступен вывод информации сессии в админке сайта

Можно удалить как отдельную сессию, так и грохнуть все сразу.
Дополнение на гитхаб
Дополнение в репозитории

Подробней под катом

Предысторию борьбы с таблицей сессий вы все наверно знаете, кто не знает пользуем поиск по данному сайту.
Под вторую версию MODX есть аналогичный пакет от Алексея Наумова.

После установки пакета меняем системную настройку session_handler_class
с
MODX\Revolution\modSessionHandler
на
ExtSession\ExtSessionHandler

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

bot_patterns — Регистронезависимый список User-Agent ботов, разделитель "|". По умолчанию —
Yandex|Google|Yahoo|Rambler|Mail|Bot|Spider|Snoopy|Crawler|Finder|curl|Wget|Go-http-client
По заданному паттерну выставляется флаг принадлежности сессии боту

bot_gc_maxlifetime — Время жизни сессии бота в секундах. Если не указан, то равно времени жизни по умолчанию — настройка «session_gc_maxlifetime»

empty_user_id_gc_maxlifetime — Время жизни сессии для Не-авторизованного пользователя в секундах. Если не указан, то равно времени жизни по умолчанию — настройка «session_gc_maxlifetime»

not_empty_user_id_gc_maxlifetime — Время жизни сессии для Авторизованного пользователя в секундах. Если не указан, то равно времени жизни по умолчанию — настройка «session_gc_maxlifetime»

show_log — Показать лог работы. Выводит отладочную информацию в журнал ошибок.

standart_clearing — Активирует стандартный запрос очистки сессии. Полезно для отладки.

Вкратце все. Если есть вопросы — задавайте.
Пакет можно скачать с гитхаб.
Володя
12 февраля 2024, 16:02
modx.pro
2
510
+12
Поблагодарить автора Отправить деньги

Комментарии: 14

Кирилл
12 февраля 2024, 19:42
0
Приветствую
Вопрос, а проводилось ли тестирование работы под нагрузкой?
Потому что на smartSessions при сроке жизнь 1 месяц, и большом количестве посещений (около полумиллиона юзеров в месяц) — сильно тормозило проект. Сильно это измерялось в секундах вроде. Боты исключались понятное дело.
    Володя
    12 февраля 2024, 19:52
    0
    Добрый вечер. Нет, тестирования под нагрузкой не проводилось. С удовольствием поучавствую в тестировании — обращайтесь.
    Потому что на smartSessions при сроке жизнь 1 месяц, и большом количестве посещений (около полумиллиона юзеров в месяц) —
    В каком месте тормозило?
      Кирилл
      12 февраля 2024, 22:35
      0
      на MODX 3 нету проекта с высокой нагрузкой для теста(
      Наумов Алексей
      12 февраля 2024, 20:36
      +1
      Просто юзеров или зарегистрированных?

      На сколько строк таблица сессий набивалась?.. интересно прост :) Я точно не тестировал на объемы, у меня крутиться на сайтах с посещаемостью до 5000 в сутки — это 150 тыс. посетителей в месяц…
      Ну и вообще, по поди какой-нибудь индекс нужно добавить или выборку улучшить, наверняка 1 узкое место
        Кирилл
        12 февраля 2024, 22:34
        0
        Под юзерами я имел в виду трафик на сайте согласно Яндекс Метрики
        А зарегистрированных около ~35 тысяч было. Это было больше года назад сейчас всех данных не вспомню, особенно по строкам

        Помню только что как только я переключил с smartSessionHandler на стандартный modSessionHandler — сразу начало работать как нужно :)

        Я обсужу с Заказчиком такой тест — и смогу в будущем поделиться данными.

        По настройкам было выставлено так:
        smartsessions_authorized_users_gc_maxlifetime = 2592000
        smartsessions_bot_signatures = DataForSeoBot|Googlebot|YandexBot|DotBot|bingbot|Mail.RU_Bot|PetalBot|MegaIndex.ru|YandexDirectDyn|Adsbot|SemrushBot|facebookexternalhit|SEO|Spider|YaDirectFetcher|BLEXBot|AhrefsBot|YandexMobileBot|MJ12bot|Barkrowler|crawler|YandexMetrika|Applebot|YandexMarket|python-urllib3|vkShare|UptimeRobot|Pinterestbot
        smartsessions_bots_gc_maxlifetime = 259200
          Володя
          13 февраля 2024, 21:18
          0
          у тебя я так понимаю так же можно вылечить modx.pro/components/24542#comment-142272
          Володя
          13 февраля 2024, 21:14
          +5
          Отписываюсь по тестированию, тестировал
          — на modhost.pro/ на тарифе разработка, сгенерировал 500 000 записей уникальных сессий с 70% ботов.
          — выделенный сгенерировал 2 000 000 записей уникальных сессий с 70% ботов.

          Далее по тексту режим:

          standart — стандартный запрос на удаление что используется в modSessionHandler
          $this->modx->removeCollection(Session::class, [
              'access:<' => time() - $this->gcMaxLifetime
          ]);

          ext — запрос на удаление что используется в ExtSessionHandler

          Сразу стало заметно тормоза:
          Session cleanup time for mode «standart»: 0.0150 s
          Session cleanup time for mode «ext»: 3.3543 s

          Был один запрос с несколькими условиями github.com/vgrish/ExtSession/blob/490dfc4a7a8f1d1dd18a988573f5b607fadc457c/core/components/extsession/src/ExtSessionHandler.php#L180-L204

          Разбил на несколько, стало чуть получше но все равно не то.
          Добавил общий индекс на 3 колонки github.com/vgrish/ExtSession/blob/8223ff63e5574b8697fcf0eb66e55c93eaba7fd6/core/components/extsession/schema/extsession.mysql.schema.xml#L36-L40

          Session cleanup time for mode «ext»: 1.3543 s — Тоже не фонтан.

          Перекинул колонки github.com/vgrish/ExtSession/blob/8223ff63e5574b8697fcf0eb66e55c93eaba7fd6/core/components/extsession/schema/extsession.mysql.schema.xml#L8-L10 перед колонкой data

          Стало еще получше.
          Ну и подумал нам же не надо прям сразу за раз удалять все записи, пускай удаляет в несколько проходов и добавил к удалению LIMIT.

          И вот тут уже стало совсем хорошо
          Session cleanup time for mode «ext»: 0.0029 s

          Так что с помощью тестов удалось найти слабое место и исправить ситуацию. LIMIT Подбирается опытным путем в зависимости от посещаемости сайта и мощности сервера. По умолчанию использовал 5000.
            Наумов Алексей
            14 февраля 2024, 10:53
            +1
            Чуть может не понял, но приведу рассуждения. Поправь, если я не прав.

            Рассматриваю ситуацию, когда базе у тебя 2 000 000 сессий, из них 1 400 000 (70%) — эт боты.
            Т.е. симулируется картина, что либо сессии продолжительное время вообще не очищались и накопились, либо у сайта ну очень высокая посещаемость.

            В первом случае, если мы поставим limit 5000, то эти сессии удалятся за 280 подходов. Ну а далее у нас будет регулярно все это работать и 2 млн сессий в базе уже не будет. По идее мы должны так сконфигурировать сервер, чтобы каждый раз при срабатывании gc() устаревало не более 5000 сессий, иначе они начнут накапливаться.

            Во втором случае (если бешеная посещаемость), хватит ли лимита в 5000 для того, чтобы удалить старые сессии? А если нет — то мы должны повысить лимит.

            И у меня возник вопрос: какая разница в обоих случаях, есть лимит или нет? Кроме первых 280 проходов, которые без лимит выполнились за 1 раз (напомню в нестандартной ситуации, что сессии ранее не очищались).

            p.s. про smartSessions:
            А в smartSessions медленная работа, думается, обусловлена LIKE поиском по колонке user_agent во время очистки и отсутствием индекса))) нужно добавить. Я когда это писал все — тормозов особо не заметил, посещаемость сайтов моих была ну до 1000 человек в сутки. Но вообще, поле is_bot реально лучше, ибо в этом случае LIKE поиск убирается, остается просто быстрый поиск по колонке tinyint. В общем если руки дойдут — изменю алгоритм.
              Володя
              14 февраля 2024, 11:05
              +1
              Все верно, но никто же не застрахован что в какой то момент времени твой сайт не подвергнется скажем атаке ботов и запрос без лимита будет вызывать задержки при работе сайте.
              пока идет запрос удаления новый пользователь не получит новый идентификатор сессии, уже действующий пользователь тоже словит задержку и будет нервно курить и в итоге закроет сайт.

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

              А в smartSessions медленная работа, думается, обусловлена LIKE поиском по колонке user_agent во время очистки и отсутствием индекса))) нужно добавить
              да, это ускорит удаление, но не сильно, в случае с большим кол-ом данных думаю будут те же тормоза что я описал выше.
          Андрей Степаненко
          16 апреля 2024, 08:25
          0
          Проанализировал код

          1. Во время удаления сессий выполняется N запросов, если быть точным то сколько прописано сигнатур user agent столь и будет выполнено запросов
          2. Поле user_agent не индексное, то есть это будут медленные запросы



          Еще хотел узнать, зачем для ботов создавать сессию?
          И потом её удалять, целесообразность этого функционал не понимаю
          особенно с учетом тяжести запросов в цикле
            Володя
            16 апреля 2024, 08:52
            0
            Привет, ты темой ошибся. Твой коммент вот сюда должен быть адресован modx.pro/components/22098
            Наумов Алексей
            16 апреля 2024, 10:00
            0
            так если про smartSessions вопрос — то я пару месяцев назад переписал это всё… сейчас по другому, в github код доступен. Можно даже PR сделать! и да, если еще вопросы будут — давай переедем в соседнюю тему, чтобы Володю не дергать)
          Авторизуйтесь или зарегистрируйтесь, чтобы оставлять комментарии.
          14