Как долго должны храниться файлы сессий magento?

Question

У меня есть клиент, чьи файлы сессий magento быстро выходят из-под контроля.Мы очищаем их один раз в неделю, но, похоже, это нужно делать чаще.

1) Что делают эти файлы?Как они связаны с работой пользователей в Интернете (например, если я удаляю их, а пользователь все еще находится на сайте, как они будут затронуты)

2) Как скоро я могу удалить их?Как долго файлы действительно должны оставаться на сервере?

Крис

Answer 1

В случае файловых сессий они автоматически удаляются с помощью cron для очистки сессий PHP, поэтому файлы могут быть удалены в течение ~ 7200 секунд после создания.Таким образом, даже на загруженном сайте (30 тыс. Уникальных файлов в день) в ./var/session обычно остается только около 4000 файлов сеансов, что не имеет значения для сервера Linux.

Однако очистка фактически зависит отcron работает - который обычно не выглядит в каталоге ./var/session Magento.Поэтому вы должны установить новую систему cron

/usr/bin/find /home/myuser/public_html/var/session -mindepth 1 -maxdepth 1 -type f -cmin +$(/usr/lib/php5/maxlifetime) -print0 -exec rm {} \; >/dev/null 2>&1

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

В сеансах Memcache TCP / IP - это единственные издержки, которые при развертывании с одним сервером замедляют работу по сравнению с файлами.Таким образом, вместо этого вы бы использовали сокет Unix, который устраняет эти издержки и повышает безопасность.Но даже при этом ваши сеансы клиентов будут сокращены / ограничены в зависимости от объема ОЗУ, которое вы можете выделить.Средний сеанс Magento составляет 4 КБ, поэтому вы сможете поддерживать 256 активных сеансов на каждый выделенный МБ.Поэтому не забудьте установить соответствующий лимит, чтобы клиенты не теряли случайно корзину / сессию.И помните, что перезапуск демона Memcache уничтожит все существующие сеансы (BAD!).

С Redis (не встроенным, но доступным через расширение) вы получаете уровень поддержки, аналогичный Memcache,но с дополнительными преимуществами настойчивости (если вы хотите использовать его).С расширением Cm_Redis вы также сможете воспользоваться преимуществами сжатия сеансов.Мы обнаружили, что это расширение очень хорошо работает в развертываниях как CE, так и EE.

При использовании DB с параметром истечения срока действия чернослива по умолчанию - 1 неделя, поэтому в качестве примера можно привести приведенный выше размер хранилища (30 тыс. Уникальныхдень), вы увидите размер таблицы БД для core_cache_session около 7 ГБ, что приведет к полной остановке вашего магазина практически для каждой операции на основе сеанса.

Из опыта хостинга как больших (230 тыс. Уникальных посетителей в день), так и небольших (<1 тыс. Уникальных посетителей в день) магазинов мы рекомендуем: </p>

Развертывание на одном сервере - файлы

Развертывание на нескольких серверах -Redis (используя отдельную базу данных из основного кэша Magento)

Я написал несколько действительно полных ответов здесь http://magebase.com/magento-tutorials/magento-session-storage-which-to-choose-and-why/comment-page-1/#comment-1980

Answer 2

Каждый файл является сеансом одного человека, и должен длиться не более session.gc_maxlifetime секунд - сборка мусора - устанавливается в файле php.ini сервера или переопределяется в .htaccess файл. Понижение этого значения означает, что будет накапливаться меньше сеансов.

У Magento есть еще одна хитрость в отношении сессий; В файле /app/etc/local.xml значение session_save может быть изменено на db, что означает, что база данных будет использоваться вместо файлов, но при этом будет учитываться вышеупомянутый срок службы сборщика мусора. Также можно указать memcache, если вы его настроили (см. /app/etc/local.xml.additional). Оба очень полезны, если сервер является кластером.

Answer 3

Не забудьте посмотреть, какая часть системы неправильно хранит необоснованные объемы данных в сеансе, чтобы фактически решить проблему. Очистка сессий раньше - это только временное исправление.

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

---

Это почти наверняка объекты, сохраняемые в сеансе, вызывая эту проблему. Распространенный шаблон в Magento - это объединение данных объекта следующим образом:

$product->
   'attr1' => 'somevalue',
   ...
   'categories' => array(
       'products' => array(
         <and so on and so forth>
       ),
   ),

Удаление объекта в сеанс может непреднамеренно включать в себя эти гигантские цепочки объектов, хранящих множество посторонних данных. Если возможно, храните в сеансе только строковые / числовые данные, например массивы идентификаторов продуктов, а не сами продукты.

Answer 4

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

Answer 5

У меня также они были накапливаться, поэтому я добавил задание cron со следующим ... (это было из инструкций в моем файле php.ini ... просто в настройке "session.gc_maxlifetime = 1440")

Например, следующий скрипт будет эквивалентен;установка session.gc_maxlifetime на 1440 (1440 секунд = 24 минуты):;найти / путь / к / сессиям -cmin +24 |xargs rm