| |||||||||
| |||||||||
28.10.2014 00:40
дело в том что то список слева который занимал максимум 5000 символов, и хранился в сессиях, его можно отдавать незареганным. а вот список который из 100 строк БД - уже значительно больше.
У сессий есть ограничение в хранении кол-ва данных, зависит от хостера, но вы должны понять весь массив сессий всегда содержится в текущей оперативной памяти (выделяемой PHP скрипту)
Т.е. чем больше данных в сессиях тем меньше остается на выполнение самого PHP скрипта и может произойти отказ из-за превышения памяти выделяемой скрипту.
Можно поступать иначе - хранить данные сессий в файлах, к примеру совпадающих с именем сессии, но часто отловить уход юзера невозможно (и соответственно очистить эти данные)
И через некоторое время - от нескольких месяцев до года мы получим тьму файлов, с данными сессий, которые либо надо удалять кроном (а он не везде есть) либо вручную админом (тоже надоест)
Поэтому я принял решение незареганным отдавать по старому макс 5000 символов (а это поисковики также, причем получающие часто по нескольку сессий) - это примерно сожрет 10Kb Оперативки умножить на кол-во юзеров в онлайне. что немного. но приходится постоянно думать и о высокой загрузки.
А зареганные хранить 100 последних товаров - полных строк БД.
Считаем - в среднем 1 строка = 4K * 100 строк = 400Kb - такой объем не желательно хранить в сессиях, поэтому храним у каждого зареганного юзера в личном кабинете и очищаем при каждом повторном заходе.
Причем учтите что корзина еще на сессиях, и еще кой какие данные в сессиях, как то - счетчик просмотренных товаров.
на 10000 товарах один счетчик может составить 10000*2b= 20kb * количество юзеров.
Так что я исчерпал хранение в сессиях и сделал правильно.
Вообще у меня складывается впечатление, что я скоро исчерпаю все ресурсы выделяемые вебсерверами - всякими доп. функциями. Придется снова заняться оптимизацией, что то переносить в AJAX - остальное в кеш, оптимизировать код. но пока полет нормальный. справляемся. EWC еще можно поставить на китайский роутер c PHP без MySQL.
Может быть когда нибудь это пригодиться? Кто знает? Вдруг выяснится какая нибудь 0-day уязвимость на MySQL и рухнет все кроме файловых баз?
У сессий есть ограничение в хранении кол-ва данных, зависит от хостера, но вы должны понять весь массив сессий всегда содержится в текущей оперативной памяти (выделяемой PHP скрипту)
Т.е. чем больше данных в сессиях тем меньше остается на выполнение самого PHP скрипта и может произойти отказ из-за превышения памяти выделяемой скрипту.
Можно поступать иначе - хранить данные сессий в файлах, к примеру совпадающих с именем сессии, но часто отловить уход юзера невозможно (и соответственно очистить эти данные)
И через некоторое время - от нескольких месяцев до года мы получим тьму файлов, с данными сессий, которые либо надо удалять кроном (а он не везде есть) либо вручную админом (тоже надоест)
Поэтому я принял решение незареганным отдавать по старому макс 5000 символов (а это поисковики также, причем получающие часто по нескольку сессий) - это примерно сожрет 10Kb Оперативки умножить на кол-во юзеров в онлайне. что немного. но приходится постоянно думать и о высокой загрузки.
А зареганные хранить 100 последних товаров - полных строк БД.
Считаем - в среднем 1 строка = 4K * 100 строк = 400Kb - такой объем не желательно хранить в сессиях, поэтому храним у каждого зареганного юзера в личном кабинете и очищаем при каждом повторном заходе.
Причем учтите что корзина еще на сессиях, и еще кой какие данные в сессиях, как то - счетчик просмотренных товаров.
на 10000 товарах один счетчик может составить 10000*2b= 20kb * количество юзеров.
Так что я исчерпал хранение в сессиях и сделал правильно.
Вообще у меня складывается впечатление, что я скоро исчерпаю все ресурсы выделяемые вебсерверами - всякими доп. функциями. Придется снова заняться оптимизацией, что то переносить в AJAX - остальное в кеш, оптимизировать код. но пока полет нормальный. справляемся. EWC еще можно поставить на китайский роутер c PHP без MySQL.
Может быть когда нибудь это пригодиться? Кто знает? Вдруг выяснится какая нибудь 0-day уязвимость на MySQL и рухнет все кроме файловых баз?