Здравствуйте!
Наверное самое сложное для человека, который хочет инвайт на Хабр — это придумать тему поста в Песочницу.
Недавно я в ленте новостей одной опен сурс CMS прочитал новость, где говорилось о переработке механизма сессий в этом движке. Новость для меня была шокирующей. Поэтому хочу написать маленький пост про эти самые сессии.
В посте рассмотрим минусы стандартных PHP сессий и подумаем как же лучше организовать механиз этих самых сессий.
Самый большой минус этих сессий — хранение информации в файлах. Вы конечно же скажите, что в настройках это всё можно изменить, но признайтесь… Вы когда-нибудь делали сайт с использованием стандарного механизма с нестандартными настройками?
Так вот о чём я… Многие программисты по незнанию или по рассеяности забывают закрывать эти самые сессии. Это конечно не страшно, но бывают случаи, когда нужно отдать много контента или файл (да-да, бывают случаи, когда отдаём файл через PHP, а nginx на машине нет) И вот когда у нас открытая сессия и браузер продолжает получать страничку или файл. PHP блокирует файл с информацией из сессии. Это очень большая проблема для пользователей. Так как пока заблокирован файл с сессией (а он, напомню, блокируется пока PHP не закончит работу) пользователь, владелец этой сессии, не сможет просматривать другие страницы. При открытии других страниц PHP скрипт будет доходить до команды session_start(); (а она, обычно, в начале программы) и скрипт начинает ждать, пока на первой вкладке с этим сайтом закончит свою работу PHP (отдаст полностью страницу или файл)
Из других минусов — это то, что будет проблематично организовать работу сессий в клайстере. Например, у Вас стоит nginx и за ним два upstream сервера. Тут каждый сервер будет хранить сессии в своей папочке и второй сервер не будет знать об изменениях в сессии на первом сервере. Это тоже решается, но решение не красивое.
Это мой любимый метод. Тут всё просто:
Присваиваем браузеру куку с уникальным хешем (самое главное не указывайте время хранения куки. Просто без времени создавайте её)
И записываем в таблицу информацию в сессии.
Прим.: таблица с сессиями должна быть отдельной от таблицы с пользователями. Не пытайтесь хранить сессии в таблице с пользователями.
Информацию в сессии можно хранить тремя способами:
Первый способ прост и удобен. Но ограничивает возможности.
Во втором способе есть очень удобное свойство — возможно делать выборку по какому-то столбцу, а значит и параметру.
Третий способ совмещает в себе простоту и удобство, а так же возможность делать выборку. Но надо сразу определиться какую информацию можно будет делать в выборке, а какую нет. Например сраницу на которой находится пользователь будем записывать в отдельную ячейку, а капчу (к примеру, которую должен ввести пользователь) будем записывать в виде serialize(); строки и в общую ячейку.
Для очистки таблицы с сессиями есть два способа:
Первый, это в конфиге задавать число от 1 до 100 и при каждой открывающейся странице делать что-то вроде $var=rand(1,100); if (ваше_число >= $var) очищаем старые сессии. Этот способ позволяет регулировать частоту очистки сессий взависимости от количества пользователей.
Второй способ для более нагруженных проектов — это cron ;]
Memcached очень удобное средство для хранения информации. Удобно хранить кеш, сессии. Но есть подводные камушки…
При старте Memcached администратор указывает сколько оперативной памяти дозволено потреблять программе. Если количество хранимой информации больше заданных лимитов, то не всё поместится. Да, конечно можно делать с большим запасом, но кто знает — может, пока Вы спите, Ваш проект получит большой прилив пользователей?
Лично я не доверяю Memcached для хранения сессий. Для кеша или менее важной информации он классный :)
Наверное самое сложное для человека, который хочет инвайт на Хабр — это придумать тему поста в Песочницу.
Недавно я в ленте новостей одной опен сурс CMS прочитал новость, где говорилось о переработке механизма сессий в этом движке. Новость для меня была шокирующей. Поэтому хочу написать маленький пост про эти самые сессии.
В посте рассмотрим минусы стандартных PHP сессий и подумаем как же лучше организовать механиз этих самых сессий.
Стандартные PHP сессии
Самый большой минус этих сессий — хранение информации в файлах. Вы конечно же скажите, что в настройках это всё можно изменить, но признайтесь… Вы когда-нибудь делали сайт с использованием стандарного механизма с нестандартными настройками?
Так вот о чём я… Многие программисты по незнанию или по рассеяности забывают закрывать эти самые сессии. Это конечно не страшно, но бывают случаи, когда нужно отдать много контента или файл (да-да, бывают случаи, когда отдаём файл через PHP, а nginx на машине нет) И вот когда у нас открытая сессия и браузер продолжает получать страничку или файл. PHP блокирует файл с информацией из сессии. Это очень большая проблема для пользователей. Так как пока заблокирован файл с сессией (а он, напомню, блокируется пока PHP не закончит работу) пользователь, владелец этой сессии, не сможет просматривать другие страницы. При открытии других страниц PHP скрипт будет доходить до команды session_start(); (а она, обычно, в начале программы) и скрипт начинает ждать, пока на первой вкладке с этим сайтом закончит свою работу PHP (отдаст полностью страницу или файл)
Из других минусов — это то, что будет проблематично организовать работу сессий в клайстере. Например, у Вас стоит nginx и за ним два upstream сервера. Тут каждый сервер будет хранить сессии в своей папочке и второй сервер не будет знать об изменениях в сессии на первом сервере. Это тоже решается, но решение не красивое.
Хранение сессий в SQL-базе
Это мой любимый метод. Тут всё просто:
Присваиваем браузеру куку с уникальным хешем (самое главное не указывайте время хранения куки. Просто без времени создавайте её)
И записываем в таблицу информацию в сессии.
Прим.: таблица с сессиями должна быть отдельной от таблицы с пользователями. Не пытайтесь хранить сессии в таблице с пользователями.
Информацию в сессии можно хранить тремя способами:
- В виде serialize(); строки
- Каждую переменную в своём столбце
- Совместив эти два способа
Первый способ прост и удобен. Но ограничивает возможности.
Во втором способе есть очень удобное свойство — возможно делать выборку по какому-то столбцу, а значит и параметру.
Третий способ совмещает в себе простоту и удобство, а так же возможность делать выборку. Но надо сразу определиться какую информацию можно будет делать в выборке, а какую нет. Например сраницу на которой находится пользователь будем записывать в отдельную ячейку, а капчу (к примеру, которую должен ввести пользователь) будем записывать в виде serialize(); строки и в общую ячейку.
Для очистки таблицы с сессиями есть два способа:
Первый, это в конфиге задавать число от 1 до 100 и при каждой открывающейся странице делать что-то вроде $var=rand(1,100); if (ваше_число >= $var) очищаем старые сессии. Этот способ позволяет регулировать частоту очистки сессий взависимости от количества пользователей.
Второй способ для более нагруженных проектов — это cron ;]
Memcached
Memcached очень удобное средство для хранения информации. Удобно хранить кеш, сессии. Но есть подводные камушки…
При старте Memcached администратор указывает сколько оперативной памяти дозволено потреблять программе. Если количество хранимой информации больше заданных лимитов, то не всё поместится. Да, конечно можно делать с большим запасом, но кто знает — может, пока Вы спите, Ваш проект получит большой прилив пользователей?
Лично я не доверяю Memcached для хранения сессий. Для кеша или менее важной информации он классный :)