Перегрузка сеанса - что такое «слишком много данных», хранящихся в сеансе в PHP? - PullRequest
7 голосов
/ 06 февраля 2010

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

$result = mysql_query('select * from table');
array_push($_SESSION['data'],new Data(mysql_fetch_assoc($result)));

У меня вопрос: есть ли предел / значительный объем информации, который можно / нужно передавать во время сеанса? Это плохой совет или значительная производительность мешает это сделать?

Ответы [ 5 ]

6 голосов
/ 06 февраля 2010

По умолчанию данные $ _SESSION хранятся на диске в каталоге / tmp вашего сервера. Пока у вас достаточно места и вы не превышаете лимит памяти PHP, все в порядке.

Однако, если вы пытаетесь кешировать запрос, который является ОДНЫМ для большего числа пользователей, вы можете использовать что-то вроде APC или memcache, не привязанное к отдельному пользователю. В противном случае вы, по сути, собираетесь кешировать один и тот же результат 1x для каждого пользователя и не использовать кеш для всех пользователей.

1 голос
/ 06 февраля 2010

Я думаю, что ответ будет зависеть от того, где вы храните свои данные и как быстро вы можете перенести их туда.

Если размер данных составляет 44 МБ, и вы находитесь в сети 1000base-T, вы можете ожидать, что для передачи данных ТАМ потребуется 1 секунда. И 1 секунду для перевода назад ..

Если вы используете локальную память, значит, у вас ограниченный объем памяти аппарата.

Если вы используете диск, то у вас есть время загрузки / сохранения (диск работает медленно).

Но учтите, что PHP имеет ограниченный объем памяти, который позволяет использовать скрипт. Я думаю, что по умолчанию установлено 8 МБ.

Если вы говорите о больших блоках данных, вы можете рассмотреть Redis , Tokyo Cabinet или другие хранилища ключей / значений. Или даже внутренний интерфейс для манипулирования данными / кэширования их для вас без передачи через PHP.

0 голосов
/ 07 февраля 2010

Ммм, сложно. Я думаю, вы могли бы сохранить это в сессии. Реальный вопрос: хотите ли вы, чтобы вся эта информация сериализировалась и десериализировалась каждый раз, когда клиент делает запрос? Я думаю, что было бы неплохо сохранить его там, если вы будете использовать всю эту информацию на каждой странице вашего сайта, но это невозможно. Было бы лучше, если бы вы сохранили эту информацию в каталоге, подобном /temptables/sometable/, и у каждого файла было имя сеанса. Вы можете использовать session_id, чтобы получить его, а также сохранить и загрузить информацию на страницах, которые вы должны использовать:

$info = unserialize(file_get_contents('/templatebles/sometable/'.session_id().'.ser'));

и сохранение с:

file_put_contents('/temptables/sometable/'.session_id().'.ser'), serialize($info));

Но вам нужно задание cron , чтобы очистить этот каталог от старого файла. Вы можете сделать это, получив сессию по имени файла и запросив некоторую переменную, например, «itsalive», используя session_start() или выполнив что-то вроде file_exists(session_save_path().'/sess_'.$session_name), чтобы проверить, следует ли вам удалить временный файл.

0 голосов
/ 06 февраля 2010

Сеанс сериализуется и записывается на диск по умолчанию, поэтому в зависимости от размера и количества пользователей все может стать медленным. Однако обе вещи могут быть изменены (см. Руководство по сеансу в http://php.net/session для всех деталей), например, используя memcache для хранения данных в памяти. Лучше всего попробовать его в среде, максимально похожей на действующую систему, и проверить полученную нагрузку и пропускную способность.

0 голосов
/ 06 февраля 2010

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

Возможно, вы захотите взглянуть на APC или memcached для кеширования результатов, поскольку это не кеш для каждого пользователя, и он использует память вместо файлов.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...