LINUX.ORG.RU

php Кеширование. Судя по всему.

 ,


0

1

Добрый день уважаемый all.

Имеется следующая проблема.
CMS modx (revo) + shopkeeper (магазин). CentOS + Apache

Собственно проблема следующая. Периодически не добавляются или не удаляются товары из корзины. Методом научно тыка установлено:

1) MODX хранит сессии в БД. Данные корзины хранятся в сессии.
2) При отключении хранения в БД, (делаем хранение в файлах) проблема исчезает.
3) Проблема проявляется только в некоторых установках.
4) В большинстве случаев (установок на разных хостингах, разными пользователями CMS) проблем при хранении сессий в БД нет.
5) Перенос проблемного сайта на другой хостинг (первый попавшийся шаред) ни чего не изменил.
6) Чистка куков, разные компьютеры разные браузеры все перепробовано. Бьюсь уже неделю.

Нагуглил аналогичные проблемы но с другими модулями для данной CMS, аналогично лечили сохранением сессий в файлах. В нагугленом обсуждении пришли к выводу, что проблема в кешировании. То есть проблема в настройках сервера.

Собственно я все время думал, что ни какого кеширования у меня нет.

По этому решил спросить, что где может кешироваться, может я чего не знаю?

# cat /etc/redhat-release 
CentOS release 5.8 (Final)
# /usr/sbin/httpd.itk -v
Server version: Apache/2.2.22 (Unix)
Server built:   Feb  1 2012 19:01:34
# apachectl -M 
Loaded Modules:
 core_module (static)
 mpm_itk_module (static)
 http_module (static)
 so_module (static)
 auth_basic_module (shared)
 auth_digest_module (shared)
 authn_file_module (shared)
 authn_alias_module (shared)
 authn_anon_module (shared)
 authn_dbm_module (shared)
 authn_default_module (shared)
 authz_host_module (shared)
 authz_user_module (shared)
 authz_owner_module (shared)
 authz_groupfile_module (shared)
 authz_dbm_module (shared)
 authz_default_module (shared)
 ldap_module (shared)
 authnz_ldap_module (shared)
 include_module (shared)
 log_config_module (shared)
 logio_module (shared)
 env_module (shared)
 ext_filter_module (shared)
 mime_magic_module (shared)
 expires_module (shared)
 deflate_module (shared)
 headers_module (shared)
 usertrack_module (shared)
 setenvif_module (shared)
 mime_module (shared)
 dav_module (shared)
 status_module (shared)
 autoindex_module (shared)
 info_module (shared)
 dav_fs_module (shared)
 vhost_alias_module (shared)
 negotiation_module (shared)
 dir_module (shared)
 actions_module (shared)
 speling_module (shared)
 userdir_module (shared)
 alias_module (shared)
 rewrite_module (shared)
 proxy_module (shared)
 proxy_balancer_module (shared)
 proxy_ftp_module (shared)
 proxy_http_module (shared)
 proxy_connect_module (shared)
 cache_module (shared)
 suexec_module (shared)
 disk_cache_module (shared)
 file_cache_module (shared)
 mem_cache_module (shared)
 cgi_module (shared)
 version_module (shared)
 php5_module (shared)
 proxy_ajp_module (shared)
 ssl_module (shared)
Syntax OK

Где еще посмотреть? Если нужны какие то еще анализы с сервера, спрашивайте выложу.


Ответ на: комментарий от Erfinder

mod_cache - Это

cache_module (shared)
 suexec_module (shared)
 disk_cache_module (shared)
 file_cache_module (shared)
 mem_cache_module

а вообще кеширование бд как настроено?

В cms или на уровне сервера?

RaDiSt
() автор топика
Ответ на: комментарий от Erfinder

Как в CMS кешируется не знаю. Собственно в эти дебри не хочу лезть. Хочу определить что сервер тут не причем.

RaDiSt
() автор топика

Ещё, наверное, можно так сделать: при обнаружении проблемы добавить в URL какой-нибудь левый параметр ?myfake=abcd и посмотреть, что будет. Если корзина не обновилась, то проблема в кэшировании на уровне приложения. Если обновилась - на уровне вебсервера.

SOmni ★★
()

2) При отключении хранения в БД, (делаем хранение в файлах) проблема исчезает.

(для сильных духом) можно сделать свой handler-прокладку для сессий заради посмотреть что конкретно происходит при ошибке

предположение 1: лимиты мать их..в файлах можно хранить много и долго. зато в СУБД быстрый доступ при высокой нагрузке

предположение 2: если mysql и apache на разных серверах - могло разъехаться время.

MKuznetsov ★★★★★
()
Ответ на: комментарий от SOmni

Не факт. Приложение может учитывать переменные GET.

Suntechnic ★★★★★
()
Ответ на: комментарий от MKuznetsov

всё равно не спится :) быстренько глянул в гугль про вашу проблему - если MySQL то верно моё предположение «номер раз» :)

размер данных сохраняемых в сессии ограничен минимальной из констант - объём памяти выделяемой скрипту, максимальный размер файла (при хранении в файлах) или максимальный размер строки/записи БД (при хранении в СУБД). у MySQL типичное ограничение на размер строки 64 кб и зависит от настроек, - а у вас ведь он скорее всего ?

Перепрыгнуть такой лимит при utf, сериализации в текст да ещё на большой коллекции (товарной корзине) легко.

глюк может не повторяться у разных хостеров из-за разных настроек - некоторые предпочитают кластеры, у некоторых разрешён InnoDB, у некоторых нет и так далее

MKuznetsov ★★★★★
()
Ответ на: комментарий от MKuznetsov

у MySQL типичное ограничение на размер строки 64 кб и зависит от настроек

Нужно хранить в mediumtext ~16 Мб или в longtext ~2Гб вместо varchar.

hidden_4003
()
Ответ на: комментарий от hidden_4003

Нужно хранить в mediumtext ~16 Мб или в longtext ~2Гб вместо varchar.

в таком случае нет надобности в mysql, blob`ы по скорости практически файлы - bdb (berkeley db или gdbm) будет яростно быстрее хоть и непривычно.

да и вообще ёмкие сессии зло. Очевидно вместо того чтобы определить место, время и условие хранения сущности (корзины в данном случае) её просто впихнули в помойку $_SESSION. Так конечно писать проще, но вот некоторые пользователи мучуются

MKuznetsov ★★★★★
()
Ответ на: комментарий от SOmni

добавление параметра в url не влияет

RaDiSt
() автор топика
Ответ на: комментарий от MKuznetsov

Лимиты буду проверять, спасибо. БД и apache на одном хосте.

RaDiSt
() автор топика
Ответ на: комментарий от MKuznetsov

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

RaDiSt
() автор топика
Ответ на: комментарий от MKuznetsov

Разговора про скорость не было, было про то что БД молча выкидывает часть содержимого.

Когда нужна скорость то выбор вообще сокращается до файлов в tmpfs либо memcached.

hidden_4003
()
Ответ на: комментарий от RaDiSt

всё одно, где-то какие-то лимиты и настройки..их достаточно много и в php и в mysql. придётся таки вам крапотливо изучать разницу в конфигах на разных серверах и логи,логи..:)

тему http://stackoverflow.com/questions/4649907/maximum-size-of-a-php-session я думаю вы также смотрели - там вполне грамотный ответ, который я фактически перевёл на русский

из разряда фантастики, по результатам ночного гугления - народ обсуждающий собственные session_handler`ы намекает что разные версии php в разной очерёдности завершают сессию, вызывают деструкторы и освобождают ресурсы. по крайней мере обходные маневры и заглушки там популярны - в подробности не вдавался, просто для себя отметил, что даже там возможны грабли

MKuznetsov ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.