Создание собственных функций для поддержки сеансов

[Sizz]

Создание собственных функций для поддержки сеансов

Стоит ли этим заниматься? Или лучше использовать встроенные?
В большой красной библии ПХП 2е издание:

Преимущества использования заказанных функций обработки сеансов при работе с базой данных MysQL следующие:
- Обеспечивается больше порядка в файловой системе
- Значительно облегчается написание программ с поддержкой сеансов на многозвенных системах
- Изменения в базе данных не затрагивают сценарии, использующие сеансы

Или применять их только для сайтов с большой посещаемостью? А что тогда со скоростью работы скриптов?

 

[Demiurg]

Посещяемость тут не причем. Если есть необходимость - пиши, нет - не пиши.

 

[Фанат]

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

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

 

[antonio]

Ромик, на производительность использование враперов сессий для хранения их в базе сильно не влияет. Проверено, мин нет .

 

[Фанат]

antonio, и тем не менее, разница есть.
База всегда является узким местом поещаемых сайтов. Зачем ее лишний - именно лишний - раз грузить?

Другое дело, Sizz, что сессии на сайте должны применяться весьма осторожно и выборочно. Единственный пример сайта, на котором сессии должны подниматься автоматом при первом же запросе сайта - это е-магазин. И то - тогда будут проблемы с поисковиками.

 

[su1d]

База всегда является узким местом поещаемых сайтов

по-моему, с этим можно поспорить. всяко, сайт, выполненный полностью на статике, будет работать заведомо быстрее динамического проекта, но мы ведь не рассматриваем абсолютную статику, верно? при хорошем проектировании и использовании БД работает вполне приемлемо быстро.

насчёт сессий. кто-нибудь скажет навскидку каким образом выполнена сборка мусора в них (у меня нет времени/желания лезть сейчас в исходники)? так или иначе, как это может быть реализовано на файлах?
ИД сессии -- случайное число, т.е. мы не знаем заведомо ВСЕХ сессий, а это значит, чтобы подчистить мусор, мы должны пробежаться ПО ВСЕМ файлам в каталоге, проверяя дату их обновления и удаляя старые, верно?

но позвольте, господа, эта процедура мне кажется намного(!) тормознее "DELETE FROM sessions WHERE time_modified < X". активных сессий на посещаемом сайте может быть как минимум "до такой-то матери", если не больше.

а ведь сборка мусора проходит с вероятностью 100% на каждом запросе (использующем сессии, да).

что получаем в итоге?
= на файлах выигрываем в чтении инфы, хоть это и спорно -- БД может срабатывать в этом плане ненамного медленнее.
= на БД выигрываем (по-моему, очень сильно) в чистке мусора, вызывающейся на каждый запрос.

вывод? кажется БД лучше.

 

[tony2001]

>насчёт сессий. кто-нибудь скажет навскидку каким образом выполнена сборка
>мусора в них (у меня нет времени/желания лезть сейчас в исходники)? так или
>иначе, как это может быть реализовано на файлах?

обычная сборка мусора, которая зависит от двух настроек:
session.gc_probability - вероятность, с которой мусорщик будет выполняться при запросе. указывается в процентах. по умолчанию - 1%
session.gc_maxlifetime - время, прошедшее с последнего обращения(или изменения?) к файлу сессии, по прошествии которого он будет удален ближайшим проходом мусорщика

>ИД сессии -- случайное число, т.е. мы не знаем заведомо ВСЕХ сессий, а это
>значит, чтобы подчистить мусор, мы должны пробежаться ПО ВСЕМ файлам в
>каталоге, проверяя дату их обновления и удаляя старые, верно?
пробегаемся мы не по всем, а только по файлам сессий.
но таки-да, проверяя дату обновляения и удаляя старые.

>но позвольте, господа, эта процедура мне кажется намного(!) тормознее "DELETE
>FROM sessions WHERE time_modified < X". активных сессий на посещаемом сайте
>может быть как минимум "до такой-то матери", если не больше.
основные тормоза могут быть в том случае, если файловая система не любит много файлов в одном каталоге.
reiserfs, например, сие явление фиолетово.

>а ведь сборка мусора проходит с вероятностью 100% на каждом запросе (использующем сессии, да).
ну если gc_probability == 100, то да.
но это нужно руками выставить, а за такое можно по тем же рукам и получить.

 

[su1d]

указывается в процентах. по умолчанию - 1%

ой ли? а не число ли там от 0 до 1, где 0 = 0%, а 1 = 100%?

пробегаемся мы не по всем, а только по файлам сессий.

ты делаешь dir() на каталог и бежишь ПО ВСЕМ файлам, лишь пропуская неподходящие по маске. кстати, чтобы распознать маску, тоже нужны ресурсы.

reiserfs, например, сие явление фиолетово.

она уже стоит на всех (ок, большинстве) хостерах или ставится по умолчанию? насколько мне известно -- нет.
с таким же успехом можно сказать, что к/к "Буран" лучше "Запорожца" =)

но это нужно руками выставить

<САРКАЗМ>если всё руками выставлять, то можно ещё подумать о компиляции РНР без функций, которые не используются в твоих скриптах. будет быстрее работать</САРКАЗМ> =))

в общем, не убедил. =)
давай ещё раз.

 

[su1d]

глянул в php.ini:

session.gc_probability = 1
session.gc_dividend    = 1000

получается 0.1%
один раз на тысячу, ага.
выходит ненапряжно для сервера, но вроде как не очень безопасно.

 

[Demiurg]

su1d, про дефолтный алгоритм чистки мусора написано в php.ini.

все зависит от того, что для нас критично. ты сам сказал, что с файлами мы выигрываем при чтении. Чистку же мусора в этом случае пользователь не замечает, так как она запускается после выполнения скрипта, и на общую производительность влияет только когда сервер перегружен.
Ис плюсов еще - не нужна БД, и ничего не надо настраивать.

 

[tony2001]

>получается 0.1%
>один раз на тысячу, ага.
гм.
почему-то в мане по ini_set() про dividend ничего не сказано.
щас патчик пошлю им...

>ты делаешь dir() на каталог и бежишь ПО ВСЕМ файлам, лишь пропуская
>неподходящие по маске. кстати, чтобы распознать маску, тоже нужны ресурсы.
ну если уж до этого опускаться, то запрос с WHERE тоже ресурсов требует.
и не факт, что меньше. я, по крайней мере, не тестил такого никогда.

>она уже стоит на всех (ок, большинстве) хостерах или ставится по умолчанию?
>насколько мне известно -- нет.
>с таким же успехом можно сказать, что к/к "Буран" лучше "Запорожца" =)
не знал, что вызову такую бурю возмущения только из-за того, что я _привел пример_.

><САРКАЗМ>если всё руками выставлять, то можно ещё подумать о компиляции РНР
>без функций, которые не используются в твоих скриптах. будет быстрее
>работать</САРКАЗМ> =))
не в тему коммент.
я говорил о том, что по дефолту настройки - 1% вероятности.
а 100%, о которых ты говорил - это явно должно быть сделано кем-то специально.

>в общем, не убедил. =)
>давай ещё раз.
получай

 

[Falc]

Фанат
>>Единственный пример сайта, на котором сессии должны подниматься автоматом при первом же запросе сайта - это е-магазин.

Интересно почему?
У меня сесия поднимается только если человек сделал заказ.

 

[su1d]

не нужна БД, и ничего не надо настраивать.

ИМХО только лишь из-за этого дефолтный режим работы сессий -- через файлы.

ну если уж до этого опускаться, то запрос с WHERE тоже ресурсов требует.

когда там индексы, по-моему это может быть практически вообще незаметно. но если уж совсем опускаться, могу намекнуть на кластер, в котором выделенный БД сервер. (упс, запрещённый приём. лана-лана, снимается, хехе)

а вообще, где-то N-дцать лет назад, когда я был намного моложе и глупее, я однажды сделал ЦГИшку на Си, которая брала инфу из текстовых файлов (одна запись -- один файл), всего лишь пробегая по каждому из них (было их около сотни где-то). ты не представляешь КАК оно тормозило!
не, оно рулило конечно... но о-о-очень медленно =)

не знал, что вызову такую бурю возмущения

да не... просто отсёк не совсем приемлемый аргумент =)

я говорил о том, что по дефолту настройки - 1% вероятности.

угу, только вон оказалось, что по дефолту даже 0.1%,
и тут уже хочется поныть насчёт безопасности: неубиваемых "вечных" админских сессий и т.п.


в общем, это... по ходу остались при своих.
гиблая тема. ну её. давай лучше спорить что лучше: Винда или Линух.
или нет... лучше Linux vs. FreeBSD! вот! =))

 

[AnToXa]

Автор оригинала: su1d
а вообще, где-то N-дцать лет назад, когда я был намного моложе и глупее, я однажды сделал ЦГИшку на Си, которая брала инфу из текстовых файлов (одна запись -- один файл), всего лишь пробегая по каждому из них (было их около сотни где-то). ты не представляешь КАК оно тормозило!
не, оно рулило конечно... но о-о-очень медленно =)

охохо, думаю, что просмотр каталога там занимал не более 10-15% времени исполнения, а скорее всего гораздо меньше

основное время: кривой анализ + запуск cgi(ох как долго)

 

[ONK]

Я косвенно тестировал работу как сессий встроенных в ПХП и самописных сессий написанных на ПХП и мускуле. Могу сказать что самописные сессии в обычном режиме работают на 25 - 35% быстрее. При сборке мусора база данных даёт ещё больший выигрыш по скорости, при чём чем больше в базе активных сессий тем более сильный выигрыш получается (десятки и даже сотни раз). Правда у мускула есть одна особенность которую надо учитывать при сборке мусора - удалённые записи на самом деле хранятся и даже выбираются из таблицы вместе с не удалёнными при запросах с сортировками, просто мускул их отфильтровывает на некоторой стадии, что приводит к многократному замедлению запросов на таблицах с большим количеством удалённых записей. Проблемма решается оптимизацией таблицы сессий после удаления из неё мусора.

Запуск ПХП сессий при тестировании съедал на моём П3-933 4 - 5милисекунд, после перехода на собственные сессии всё ограничилось 3 запросами (два на выборку 1 на обнвление) которые работют в среднем не более 3милисекунд. 2 запроса на выборку связаны с наложением на сесии дополнительной функциональности, если использоать сессии только по прямому назначению то результат будет ещё лучше.

 

[tony2001]

su1d
кстати, gc_dividend поменяли на gc_divisor уже.