Существуют ли потенциальные проблемы с большими значениями параметров session.sid_length и session.sid_bits_per_character?

Question

[chernopazova]

Например, дано:
1) session.sid_length=128, session.sid_bits_per_character = 4
2) Идентификатор сессии меняется часто, допустим раз в полчаса
3) Средний онлайн = 10к пользователей

Так вот, может ли постоянная генерация длинных идентификаторов сессии создать существенную нагрузку на железо?
Или что-нибудь еще?

Comments

[Vitsliputsli]

2) Идентификатор сессии меняется часто, допустим раз в полчаса

Вы его сами меняете? Или как?

[chernopazova]

Vitsliputsli, ну да, через session_regenerate_id.

Answer 1

[Александр Аксентьев]

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

А сколько вам надо-то? В документации указан максимум если он есть или оптимальное значение.

session.sid_length integer
session.sid_length позволяет указать длину идентификатора сессии. Это значение должно быть в диапазоне 22-256

session.sid_bits_per_character integer
session.sid_per_character позволяет задать количество бит в одном символе идентификатора сессии. Доступные значения '4' (0-9, a-f), '5' (0-9, a-v), и '6' (0-9, a-z, A-Z, "-", ","). По умолчанию 4. Чем больше бит, тем сильнее идентификатор сессии. В большинстве окружений рекомендуется 5.

2) Идентификатор сессии меняется часто, допустим раз в полчаса
3) Средний онлайн = 10к пользователей

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

Comments

[chernopazova]

Документацию читала. Мой вопрос скорее о практическом опыте, не о теории. Если смотреть на ситуацию с точки зрения здравого смысла, требуется больше ресурсов для генерации ID длиной 128 символов по сравнению с 32 символами (при одинаковом session.sid_bits_per_character integer). Может, предложите идею, как провести сравнительный тест?

[Александр Аксентьев]

chernopazova, практический опыт из моих уже около 5-10 лет, я никогда даже не пытался менять эти значения и не знал про них.

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

Единственные "проблемы" с дефолтными сессиями начинаются когда проект начинает хоститься более чем на одном сервере, и это решается установкой memcache/redis в качестве хранилища сессий т.е. двумя строками кода или конфига: https://ruhighload.com/%D0%A1%D0%B5%D1%81%D1%81%D0...

О проблемах с безопасностью никаких не слышал. Все проблемы безопасности/в работе находятся так или иначе в коде приложения если они есть. Когда ввод пользователя пишется в сессию без должной проверки или вообще без проверки и всё такое.