Я видел только примеры переменных сеанса, которые используются для хранения небольших объемов данных, например, одного идентификатора пользователя. Мне интересно, было бы более эффективным вместо этого хранить более часто используемые данные в переменных сеанса, чтобы избежать запросов к базе данных.
Например, я создал пользовательский класс, который собирает регулярно запрашиваемые данные для этого пользователя при построении (их идентификатор пользователя, имя пользователя, адрес электронной почты, пароль и массивы данных сайта), и я считаю этот экземпляр переменной сеанса. После первоначального входа в систему база данных редко запрашивается для получения информации о пользователе, поскольку она уже находится в памяти.
Действительно ли я вообще эффективнее, или я просто увязываю систему с использованием памяти?
Боковое примечание. На самом деле мне легче брать данные из сеанса, а не беспокоиться о том, как оптимизировать мои запросы и прочее, поэтому я действительно надеюсь, что я не буду идиотом.
Во-первых, PHP-сессии по умолчанию не хранятся в памяти , они хранятся на диске, поэтому каждый блок / сеанс, который вы пишете, занимает занимаемое дисковое пространство, а не память (пока вы не используете PHP для чтения данных сеанса).
Да, вы потенциально более эффективны, но не хотите масштабировать и вот почему:
Это вполне приемлемо для хранения некоторых данных в сеансах. Теоретически, нет предела (хотя я никогда не пытался его сломать или даже подтолкнул, просто перейдем к более эффективному решению). Однако вы будете ограничены дисковым пространством и PHP memory_limit() .
Часто данные, хранящиеся в сеансах, включают такие вещи, как:
Однако есть компромисс. Если ваш трафик (и использование) увеличивается, и вы храните много данных в $_SESSION , вы, скорее всего, начнете видеть проблемы как с точки зрения использования диска, так и с использованием памяти.
Я не думаю, что есть какие-то проблемы с тем, что вы предлагаете, но помимо перечисленных вами элементов и где вышеприведенные примеры перекрываются, требуется уход.
Если вы хотите масштабировать (горизонтально) и сохранять сеансы на основе диска, тогда у вас есть параметры ( липкие сеансы или сеть хранилищ – пара), так как диск на одном сервере не хранит те же сеансы, что и диск на другом сервере.
Вы можете найти местоположение, где PHP хранит данные сеанса, вызывая: session_save_path()
или в CLI:
php -r 'echo session_save_path(), "\n";'
Вы не упомянули свою ОС, но общие места для файлов сеанса (в разных типах ОС):
/tmp /var/lib/php5/ /var/lib/php/session c:/wamp/tmp
Сессии, хранящиеся на диске, обычно имеют имена файлов, которые выглядят так: ls -al :
-rw------- 1 www www 0 2013-07-09 20:12 sess_bdsdjedmvtas5njhr5530b8rq6
Стоит отметить, что часто происходят процессы сбора мусора, которые очищают мертвые сессии после определенных периодов. Это зависит от ОС, но они обычно присутствуют с различными установками на основе LAMP.
В вашей базе данных
Данные сеанса часто хранятся в БД, а не на локальном диске, и это хорошо работает для малых, малых и (в зависимости от того, как это делается) средних сайтов с разумным уровнем трафика.
Как и любое другое решение, у него есть pro и con (например, возможность запретить / выгнать пользователя, выполнив запрос, а не удалив файл сеанса из /tmp )
В памяти
для более крупных (более дорогих) сайтов и особенно там, где объем одновременных пользователей высок, память быстрее считывает / записывает для очень часто используемых переменных или данных вместо того, чтобы добавлять чрезмерную нагрузку на вашу БД. Он может и должен записываться в БД (см. Кэширование путем записи ), но также должен храниться в памяти для эффективного доступа.
Одним из достоинств метода является кэширование памяти . Широко используемым примером PHP-совместимого решения с открытым исходным кодом является Memcached , который может использоваться на одном сервере или многих [распределенных]. Я видел, что это использовалось небольшими фирмами, а также большими, и вам нужно только посмотреть, кто его использует / способствует …
Все зависит от ресурсов сервера и от одновременных пользователей вашего сайта / приложения.
Вы можете сделать грубый расчет, оценив среднюю сессионную память, которая потребуется каждому пользователю, умножая ее на среднее число одновременных посетителей и сравнивая ее с памятью, доступной для PHP на сервере.
Этот расчет поможет вам оценить, насколько много в вашем сценарии, очень грубо, но полезно.
EDIT: по памяти я имею в виду RAM и / или дисковое пространство, в зависимости от вашей настройки.
Некоторые из других ответов предполагают, что вы имеете в виду использование сеансов PHP для кэширования данных. Это хорошее решение для хранения эфемерных данных, которые должны быть доступны с одного запроса на следующий.
Но мне интересно, имеете ли вы в виду использование пользовательских переменных MySQL . Вы можете хранить длинные строки данных в этих переменных, и они занимают ОЗУ в области потока вашей базы данных на сервере MySQL. Но эти пользовательские переменные не остаются в памяти после закрытия сеанса. Они не являются хорошим способом хранения данных с одного запроса на следующий.
Единственная причина для хранения больших объемов данных в пользовательских переменных заключается в том, что вам нужно использовать их в последующих SQL-запросах во время одного и того же сеанса db (что означает, что в течение одного и того же запроса PHP), и вы надеетесь избежать передачи этой строки из db для вашего приложения. В противном случае вы можете также получить результат и сохранить его в переменной PHP.
Другим решением для хранения эфемерных данных является использование memcached . Вы можете хранить данные напрямую, или вы можете использовать memcached в качестве хранилища резервных копий для вашей сессии PHP .
Попытайтесь иметь в виду, что веб-парадигма поощряет модель памяти без состояния. То есть загрузите то, что вам нужно, чтобы отобразить страницу, отобразить страницу и освободить ресурсы.
Очевидно, что есть время для кэширования данных, но да, хранение информации в переменных сеанса создает больше использования памяти для вашего приложения в целом, а EACH SESSION будет использовать все N байтов, которые вы храните.
Если у вас нет проблемы с производительностью, не беспокойтесь о кешировании. С другой стороны, если вы хотите кэшировать, и это только на одном сервере для небольшого числа пользователей, не беспокойтесь об этом. Просто имейте в виду недостатки использования переменных сеанса в веб-ферме (если вы их используете).