Я работаю с несколькими веб-серверами за балансировщиком нагрузки, и я могу включить Sticky Sessions, чтобы удерживать пользователя на определенных веб-серверах – это сработает.
Я читал о сессиях PHP и MemCache. Я должен сказать, что то, что я прочитал, – это путаница, так как некоторые страницы говорят о своей хорошей идее, а другие – наоборот.
Вопросов:
1: ДА. И я настоятельно рекомендую хранить PHP-сессии в Memcached. Вот почему:
Memcached отлично подходит для хранения небольших фрагментов данных, к которым часто обращаются базы данных и файловая система.
Memcached был разработан специально для сеансов. Первоначально это было детищем ведущего разработчика livejournal.com, а позже использовалось также для кэширования содержимого сообщений пользователей. Выгода была немедленной: большинство действий происходило в памяти. Время загрузки страницы значительно улучшилось.
К счастью, PHP и Apache имеют легкую реализацию для обработки сеансов с Memcached. Просто установите несколько команд оболочки
пример для debian:
sudo apt-get -t stable install php5-memcached а также
измените настройки php.ini на нечто похожее:
(взято из http://www.dotdeb.org/2008/08/25/storing-your-php-sessions-using-memcached/ )
session.save_handler = memcache ; change server:port to fit your needs... session.save_path="tcp://server:port?persistent=1&weight=1& timeout=1&retry_interval=15"
Ключ – session.save_path
Он больше не будет указывать на относительный путь к файлу на вашем сервере. APC был упомянут – APC для кэширования файлов .php, используемых программой. APC и Memcached значительно сократят IO и освободят Apache для более эффективного использования ресурсов, таких как изображения.
2: Нет
3: Основным недостатком использования Memcached является волатильность данных
Данные сеанса не сохраняются в Memcached. Поэтому, если и когда сервер сбой, все данные в памяти теряются. Каждый должен будет снова войти в систему.
И тогда у вас есть потребление памяти …
Помните: сеансы хранятся в памяти. Если ваш сайт обрабатывает большое количество одновременных пользователей, вам может потребоваться выложить немного дополнительных денег для большего объема памяти.
Наконец, латентность (не глупая)
Это ставит все в будущее. Если вы не планируете выполнять все действия на одной машине, вы в конечном итоге масштабируете свой memcached-кластер по сети серверов. (Это масштабирование горизонтально). Латентность может оказать существенное влияние на производительность и пропускную способность, когда не обрабатывается требуемое количество аппаратных средств для обработки требований нагрузки.
Например, экземпляры Amazon EC2 имеют задержку около 80 мс, а самая дорогая операция в моем приложении занимает около 70 мс для выполнения и кэширования одной страницы. Некоторые из самых быстрых страниц занимают 1-2 мс, но теперь они составляют 81 мс с штрафом в 80 мс. Поэтому вместо того, чтобы думать, что добавление 2 серверов будет «утроить» мою емкость, я ошибаюсь. Возможно, 5-10 серверов? Не существует формулы для определения оптимального числа после обновления, поскольку единственный способ узнать – измерить трафик по мере его поступления и развернуть новые серверы по мере необходимости. Еще одно соображение $$$, но вы можете масштабировать до бесконечности по дешевке, потому что получение большей пропускной способности с большим количеством аппаратного обеспечения всегда было легкой частью!
Расширение memcache даже поставляется с обработчиком сеанса, который требует очень небольшой конфигурации для запуска и запуска. http://php.net/manual/en/memcached.sessions.php
Я действительно не знаю, что «лучше». Я чувствую, что это будет один из ответов «это зависит». Вероятно, это зависит от ваших причин балансировки нагрузки. Если небольшое количество пользователей вызывает большую нагрузку каждый или большое количество, вызывающее небольшую нагрузку.
Вероятно, есть 2 основных недостатка в использовании memcache для хранения сеансов.
Во-первых, он неустойчив. Это означает, что если один из ваших экземпляров memcached перезагружен / сработал и т. Д., Любые сеансы, хранящиеся в этом экземпляре, будут потеряны. Хотя, если они используют традиционные сеансы на основе файлов, они будут все еще там, когда сервер вернется.
Во-вторых, и, вероятно, более уместно, memcached не гарантирует устойчивость, он предназначен только для кеша. По любой причине данные могут быть удалены из memcached в любое время. Хотя, на самом деле, единственные причины, которые должны быть очищены, – это если кеш близится к его размерам. Самые последние данные будут удалены. Опять же, это может не быть проблемой, поскольку пользователь, вероятно, ушел, если их сеанс устарел, но это зависит от ваших потребностей.
Поскольку моя точка зрения не рекомендуется хранить сеансы в Memcached. Если сеанс исчезает, часто пользователь выходит из системы. Если часть кеша исчезает или из-за сбоя оборудования, это не должно вызывать у пользователей ощутимую боль. «memcached», «memcached» – это высокопроизводительная система кэширования объектов с распределенной памятью, которая носит общий характер, но предназначена для использования в ускорении динамических веб-приложений путем облегчения загрузки базы данных ». Поэтому, разрабатывая приложение, помните, что вы должны иметь чтобы вернуть данные, если они не найдены на сервере Memcached.
Если вы хотите использовать расширение «memcacheD», а не «memcache» (есть два разных расширения) для управления сеансом, вам следует обратить внимание на изменение php.ini .
Большинство веб-ресурсов Google основаны на memcache, потому что это более ранняя версия, чем memcacheD. Они скажут следующее:
session.save_handler = memcache session.save_path = "tcp: // localhost: 11211"
Но это недействительно, когда дело доходит до memcacheD.
Вы должны изменить php.ini следующим образом:
session.save_handler = memcached session.save_path = "localhost: 11211"
Нет идентификатора протокола.