[ExtSession] - Расширение стандартных сессий для MODX3
[ExtSession] — Компонент расширяет класс modSession, добавляет следующие поля в родную таблицу сессий.
Доступен вывод информации сессии в админке сайта
Можно удалить как отдельную сессию, так и грохнуть все сразу.
Дополнение на гитхаб
Дополнение в репозитории
Подробней под катом
Предысторию борьбы с таблицей сессий вы все наверно знаете, кто не знает пользуем поиск по данному сайту.
Под вторую версию MODX есть аналогичный пакет от Алексея Наумова.
После установки пакета меняем системную настройку session_handler_class
с
Далее идем в настройки пакета и конфигурируем пакет под свои требования.
bot_patterns — Регистронезависимый список User-Agent ботов, разделитель "|". По умолчанию —
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 — Активирует стандартный запрос очистки сессии. Полезно для отладки.
Вкратце все. Если есть вопросы — задавайте.
Пакет можно скачать с гитхаб.
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 — Активирует стандартный запрос очистки сессии. Полезно для отладки.
Вкратце все. Если есть вопросы — задавайте.
Пакет можно скачать с гитхаб.
Поблагодарить автора
Отправить деньги
Комментарии: 14
Приветствую
Вопрос, а проводилось ли тестирование работы под нагрузкой?
Потому что на smartSessions при сроке жизнь 1 месяц, и большом количестве посещений (около полумиллиона юзеров в месяц) — сильно тормозило проект. Сильно это измерялось в секундах вроде. Боты исключались понятное дело.
Вопрос, а проводилось ли тестирование работы под нагрузкой?
Потому что на smartSessions при сроке жизнь 1 месяц, и большом количестве посещений (около полумиллиона юзеров в месяц) — сильно тормозило проект. Сильно это измерялось в секундах вроде. Боты исключались понятное дело.
Добрый вечер. Нет, тестирования под нагрузкой не проводилось. С удовольствием поучавствую в тестировании — обращайтесь.
Потому что на smartSessions при сроке жизнь 1 месяц, и большом количестве посещений (около полумиллиона юзеров в месяц) —В каком месте тормозило?
на MODX 3 нету проекта с высокой нагрузкой для теста(
Просто юзеров или зарегистрированных?
На сколько строк таблица сессий набивалась?.. интересно прост :) Я точно не тестировал на объемы, у меня крутиться на сайтах с посещаемостью до 5000 в сутки — это 150 тыс. посетителей в месяц…
Ну и вообще, по поди какой-нибудь индекс нужно добавить или выборку улучшить, наверняка 1 узкое место
На сколько строк таблица сессий набивалась?.. интересно прост :) Я точно не тестировал на объемы, у меня крутиться на сайтах с посещаемостью до 5000 в сутки — это 150 тыс. посетителей в месяц…
Ну и вообще, по поди какой-нибудь индекс нужно добавить или выборку улучшить, наверняка 1 узкое место
Под юзерами я имел в виду трафик на сайте согласно Яндекс Метрики
А зарегистрированных около ~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
А зарегистрированных около ~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
у тебя я так понимаю так же можно вылечить modx.pro/components/24542#comment-142272
Отписываюсь по тестированию, тестировал
— на modhost.pro/ на тарифе разработка, сгенерировал 500 000 записей уникальных сессий с 70% ботов.
— выделенный сгенерировал 2 000 000 записей уникальных сессий с 70% ботов.
Далее по тексту режим:
standart — стандартный запрос на удаление что используется в modSessionHandler
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.
— на 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.
Чуть может не понял, но приведу рассуждения. Поправь, если я не прав.
Рассматриваю ситуацию, когда базе у тебя 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. В общем если руки дойдут — изменю алгоритм.
Рассматриваю ситуацию, когда базе у тебя 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. В общем если руки дойдут — изменю алгоритм.
Все верно, но никто же не застрахован что в какой то момент времени твой сайт не подвергнется скажем атаке ботов и запрос без лимита будет вызывать задержки при работе сайте.
пока идет запрос удаления новый пользователь не получит новый идентификатор сессии, уже действующий пользователь тоже словит задержку и будет нервно курить и в итоге закроет сайт.
Так вот чтобы не было тормозов я и решил ввести limit, нам же не принципиально очистить таблицу за один проход.
пока идет запрос удаления новый пользователь не получит новый идентификатор сессии, уже действующий пользователь тоже словит задержку и будет нервно курить и в итоге закроет сайт.
Так вот чтобы не было тормозов я и решил ввести limit, нам же не принципиально очистить таблицу за один проход.
А в smartSessions медленная работа, думается, обусловлена LIKE поиском по колонке user_agent во время очистки и отсутствием индекса))) нужно добавитьда, это ускорит удаление, но не сильно, в случае с большим кол-ом данных думаю будут те же тормоза что я описал выше.
Проанализировал код
1. Во время удаления сессий выполняется N запросов, если быть точным то сколько прописано сигнатур user agent столь и будет выполнено запросов
2. Поле user_agent не индексное, то есть это будут медленные запросы
Еще хотел узнать, зачем для ботов создавать сессию?
И потом её удалять, целесообразность этого функционал не понимаю
особенно с учетом тяжести запросов в цикле
1. Во время удаления сессий выполняется N запросов, если быть точным то сколько прописано сигнатур user agent столь и будет выполнено запросов
2. Поле user_agent не индексное, то есть это будут медленные запросы
Еще хотел узнать, зачем для ботов создавать сессию?
И потом её удалять, целесообразность этого функционал не понимаю
особенно с учетом тяжести запросов в цикле
Привет, ты темой ошибся. Твой коммент вот сюда должен быть адресован modx.pro/components/22098
спасибо) не увидел
так если про smartSessions вопрос — то я пару месяцев назад переписал это всё… сейчас по другому, в github код доступен. Можно даже PR сделать! и да, если еще вопросы будут — давай переедем в соседнюю тему, чтобы Володю не дергать)
ок)
Авторизуйтесь или зарегистрируйтесь, чтобы оставлять комментарии.