В этом сообщении блога показаны результаты сравнения производительности различных механизмов хранения сессий с Magento, и они, похоже, пришли к выводу, что до 75 одновременных пользователей разницы в производительности между ними нет.
Я думаю, что на этих уровнях (у них было около 5 транзакций в секунду, что составило бы около 430 тыс. Обращений за 12-часовой период) накладные расходы во всем остальном преобладают над показателями производительности, которые вы видите, так как файл / DB / Memcache / Redis все будут обрабатывать с удовольствием трафик, не нарушая пот при правильном использовании.
Это оставляет другие факторы, такие как масштабируемость, надежность и безопасность.
Прежде всего, я бы хотел сказать, что все, что подрывает ваше файловое хранилище, вероятно, подорвет что-либо еще, так как злоумышленник может просто изменить код вашего приложения или, по крайней мере, обнаружить ключи и протоколы / учетные данные для доступа к хранилищу, даже если они имеют только чтение. доступ. Файловое хранилище будет хорошо работать для сайта с небольшим объемом, его легко настроить и легко обдумать. Если вы говорите, что попали на диск, чтение из БД также попадет на диск, и, если БД сможет его кешировать, ваша ОС, скорее всего, также кеширует файл сеанса. Кроме того, он прочитан одним файлом, и ваша файловая система прекрасно справится с задачей, если вы уже знаете его имя. Если вы используете PHP, знаете ли вы, сколько операций чтения файлов требуется системе для обслуживания вашего приложения? Недостатком является то, что вы можете
Memcache является относительно быстрым, и если вы рассматриваете классовые решения Memcache более широко (Redis и т. Д.), Есть такие, которые даже обещают постоянство при чтении в памяти для скорости, так что вы получите максимум от обоих миров. Они также относительно просты для рассуждения, и природа сеансов ключ-значение - это именно то, для чего они были предназначены. Знаете ли вы, сколько вам придется потратить на сессию, чтобы заполнить одну из них? В любом случае, все ваши варианты заставят вас пойти на компромисс, если вы достигнете их возможностей. Диски заполняются файлами (здесь указан коэффициент количества и размера), емкости кэш-памяти заполняются, а базы данных имеют ограниченное количество строк и те же ограничения емкости диска, что и файловый подход. Кроме того, эти системы распространяются только в том случае, если вы запускаете их распределенным способом. Большинство работает просто отлично с настройкой одного сервера. Если вы распространяете их, то, вероятно, у вас уже есть распределенные веб-серверы / серверы баз данных и т. Д., Поэтому проблемы с распределенной системой, безусловно, не будут отображаться при выборе хранилища сеансов. Тем не менее, когда вам требуется 10-кратный трафик / емкость и т. Д., Добиться этого гораздо естественнее, чем схемы хранения файлов. Некоторые хранилища ключей / значений также позволят вам сравнительно легко провести простой анализ данных сеанса, но большинство из них не приблизят вас к возможностям SQL.
Я не уверен, почему вы предлагаете, чтобы база данных была более надежной, чем другие варианты, но я понимаю привлекательность базы данных, поскольку ваше PHP-приложение, вероятно, уже использует ее. Это означает, что вы не добавляете другую зависимость от сервера и, вероятно, можете повторно использовать то же соединение, которое используете для извлечения данных сеанса, чтобы получить пользовательские данные, поэтому вам не нужно устанавливать одно для данных, другое для Memcache и т. Д. Если вы индексируете Что касается таблицы, то она также будет работать достаточно быстро и предоставляет довольно простую семантику, с которой вы уже знакомы, для того, чтобы пожинать старые сеансы или даже анализировать данные сеансов (я не уверен, почему вы захотите, а если нет, то, вероятно, это не так). это не имеет большого значения). Масштабирование до масштабных масштабов не так тривиально, как с чем-то вроде Redis,
Я думаю, что этот выбор не так важен в начале. У каждого подхода есть проблемы, преимущества и вещи, о которых вы должны подумать. Вообще говоря, вы, вероятно, можете обойтись, просто используя значения по умолчанию PHP / любой другой фреймворк, который вы используете, или даже просто самое простое в использовании. Если впоследствии выбор окажется неудачным, ваша аналитика производительности скажет вам, и вы будете вооружены данными, которые вам необходимы, чтобы сделать правильный выбор, учитывая конкретный характер получаемого вами трафика. Вначале все, что вы можете разумно иметь, это общие предположения.