Создавать сессии только для залогиненых пользователей?

Question

[Powerhead]

Механизм сессий в php таков, что для каждого уникального посетителя на сервере создается файл идентификатор сессии. С наплывом посетителей файлов стало создаваться чрезмерно много.
Хочу посоветоваться, имеет ли смысл запускать сессию исключительно для залогиненых пользователей поскольку последних намного меньше?

Если у клиента есть куки с session id, значит клиент залогинен то запускать session_start()
Если куки нет — значит не залогинен, сессию не запускаем.

Подскажут ли уважаемые гуру, поможет ли это выиграть в производительности сервера?

Answer 1

[rakot]

Храните сессии в Redis

Comments

[rakot]

Интересно из каких соображений получил минус? При 200+ конкурентных запросов, если на каждого создаётся файл сессии, то мы получаем блокировку, т.к. диск больше не тянет. Это абсолютно ненужная нагрузка, диск за это вам спасибо не скажет.
Редис в качестве хранилища для сессий настраивается с полпинка.

Если даже, есть и другие узкие места, то этот механизм лишним не будет.

Answer 2

[Vampiro]

ИМХО вы не в ту сторону копаете. Создание файла крайне дешевая операция, лучше оптимизируйте свой «битрикс»…

Answer 3

[cronfy]

Следствие присутствия session_start() в начале скрипта таково: если клиент не поддерживает куки, то файл сессии создается на каждый запрос. А всякие роботы довольно часто куки не поддерживают.

Еще раз — на каждый запрос робота создается новый файл сессии.

Если у вас сессии хранятся, скажем, 24 минуты (по умолчанию), то это еще не очень сказывается. Но когда вы решите увеличить время хранения сессии до месяца, чтобы пользователя из корзины не выбрасывало, то довольно скоро у вас в tmp/ накопится под миллион файлов. В результате PHP при открытии страницы или очистке мусора будет работать медленно и ощутимо тратить ресурсы сервера.

Поэтому рекомендация такая: храните сессии для пользователей, которые сохраняют ваши куки. Ставим куку, проверяем на следующем запросе, есть ли эта кука, если есть — можно запускать session_start().

Вариант проще, без кук, и будет создаваться еще меньше сессий: создавать сессию только для того, кто авторизовался. То есть, пока не совпал логин и пароль пользователя, не запускаем session_start().

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

Если у клиента есть куки с session id, значит клиент залогинен то запускать session_start()
Если куки нет — значит не залогинен, сессию не запускаем.

Если есть куки с ID сессии, значит, вы уже вызвали session_start(), а значит, файл сессии уже создался. Проверять нунжо как-нибудь по-другому (например, совпадением введенного логина и пароля, как описано выше).

Comments

[Powerhead]

Если у вас сессии хранятся, скажем, 24 минуты (по умолчанию), то это еще не очень сказывается. Но когда вы решите увеличить время хранения сессии до месяца, чтобы пользователя из корзины не выбрасывало, то довольно скоро у вас в tmp/ накопится под миллион файлов. В результате PHP при открытии страницы или очистке мусора будет работать медленно и ощутимо тратить ресурсы сервера.

Именно это и произошло. Проект уже довольно сложный, напиан на ZF, с наплывом посетителей и созданием миллионов сессий стал еле работать. Поэтому встали вопросы по изменению архитектуры. Увы, придется перелопатить массу кода, чтобы изменить архитектуру сессий.

[cronfy]

Можно взглянуть на это с другой стороны: ниже egorinsk высказал хорошую идею про инкапсуляцию, а рефакторинг делает ваш код лучше :)

Answer 4

[Артур Кох]

Зачем незалогиненному sid? Я не говорю об оптимизации. Просто по логике. Не надо, не запускай.

Comments

[Powerhead]

Для сбора какой-нибудь статистики например

[Артур Кох]

Тогда оставить сессии, если это необходимо.

[Назар Мокринский]

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

Answer 5

[Николай Васильчук]

Я не разделяю пользователей. Для всех стартует сессия и даются права. Для анонимных — минимум прав, для авторизованных — побольше.

Comments

[impass]

Я не разделяю пользователей. Для всех стартует сессия и даются права.

Казалось бы, в чём тут обязательность использования сессии? Нет сессионных куки или пользователь неаутентифицирован — считать его анонимным.

[Николай Васильчук]

Lux_In_Tenebris, это удобно. Один алгоритм для всех пользователей. Позднее усовершенствовал алгоритм, сессия теперь стартует при первом обращении к ней. Смысл от этого не меняется.

[vsespb]

удобно, неудобно. это же в одном месте можно закодировать. потом только иметь дело с понятиями «не аутентифицированный пользователь» и «аутентифицированный пользователь», ничего не зная про сессии. авторизация отдельно от аутентификации.

Answer 6

[R0ckwi11]

А сессии вообще и в БД хранить можно, рекомендую.
Даже если сейчас для незалогиненых пользователей сессия не нужна, она может понадобиться потом, так что ИМХО стоит

Comments

[Juggler]

Хранение сессий в БД реализовано в ShopCMS. Можно посмотреть у них в исходниках.

Answer 7

[impass]

Хочу посоветоваться, имеет ли смысл запускать сессию исключительно для залогиненых пользователей поскольку последних намного меньше?

На самом деле, так и должно быть почти всегда. Разработчки тех или иных веб-приложений так зачастую сами плохо представляют, что впустую созданная сессия до момента собственно аутентификации ни для чего не нужна. Для целей сбора какой-либо статистики посещения стоит изобретать решение, не зависящие от основной сессии: выставление куки для дополнительных субдоменов или конкретных путей сайта и т.п.
В случаях, когда, например, необходимо настроить кэширование ответов backend'а на сильно нагруженных сайтах, отключить создание сессии для каждого входящего — просто жизненно необходимо.

Answer 8

[stanishevsky]

А совсем по-хорошему, кроме создания сессии только для залогиненных пользователей (что, вообще говоря, правильно), поставьте перед веб-сервером реверс-прокси — nginx или varnish (рекомендую последний), которые будут проверять наличие куки залогиненного пользователя, и в случае ее отсутствия выдавать контент из своего кеша. Таким образом, вы вообще не будете запускать PHP для незалогиненных пользователей.

Вот, например, как решается эта проблема в друпале (неважно, что у вас, принципы, скорее всего, те же) www.varnish-cache.org/trac/wiki/VarnishAndDrupal

Answer 9

[Angerslave]

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

Answer 10

[egorinsk]

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

Вам уже советовали хранить сессии в редисе, можно так же в БД их попробовать хранить.

Answer 11

[softm]

Почему бы не попробовать, идея хорошая, по-моему.
Может будет немного выигрыша по быстродействию.