здравствуйте,
я сверстал сайт на ModX Revolution. после перевода траффика на новую версию сайта, CMS загрузила процессор на 100%. темп увеличения количества записей в базе данных очень высокий, и винчестер постоянно сильно загружен. я не нашел возможность перенести записи о сессиях пользователей в cookies вместо sessions id в таблице базы данных. CMS не справляется с траффиком всего в 30 тыс. посетителей в день, это очень мало. что вы можете посоветовать?
За один час количество записей в таблице sessions увеличилось на 23125 записей
дай всю инфраструктуру, что имеешь, сколько посетителей в пике и нагрузки в пике, которые имеешь.
Около 100 человек в минуту, нагрузка процессора - 100%, диск - 20 000 000 байт в минуту. Возможно даже не в пике, пришлось отключить CMS по достижении 100% нагрузки
OS?
Apache/nginx?
php?
вывод htop - кто жрет память
Note: If you’re posting about a bug, please state all of your Environment information in your post: Version of MODx, Traditional or Advanced distribution (for Revo), Server OS, Server Version, PHP Version, MySQL Version (client and server), is pdo_mysql installed, your Browser type and version, if you are using any opcode caching such as eAccelerator, APC, winCache, xCache, etc; any relevant errors in core/cache/logs/error.log, and any other environment data we should know. We can’t help you without that information.
Modx Revolution 2.0.4-pl2 traditioanal
Сервер - Apache/2.2.9 (Fedora)
Система Linux Fedora
PHP Version 5.2.6
MySQL Версия сервера: 5.0.45, Версия клиента: 5.0.45
pdo_mysql установлен
CMS использует только getResourses, getPage, GetCache. Всего на сайте около 30 страниц.
Лог ошибок:
Error preparing statement for query: SELECT `modSession`.`id` AS `modSession_id`, `modSession`.`access` AS `modSession_access`, `modSession`.`data` AS `modSession_data` FROM `modx_session` AS `modSession` WHERE `modSession`.`id` = ? - Array ([0] => 00000)
Error preparing statement for query: SELECT `modSnippet`.`id` AS `modSnippet_id`, `modSnippet`.`name` AS `modSnippet_name`, `modSnippet`.`description` AS `modSnippet_description`, `modSnippet`.`editor_type` AS `modSnippet_editor_type`, `modSnippet`.`category` AS `modSnippet_category`, `modSnippet`.`cache_type` AS `modSnippet_cache_type`, `modSnippet`.`snippet` AS `modSnippet_snippet`, `modSnippet`.`locked` AS `modSnippet_locked`, `modSnippet`.`properties` AS `modSnippet_properties`, `modSnippet`.`moduleguid` AS `modSnippet_moduleguid` FROM `modx_site_snippets` AS `modSnippet` WHERE `modSnippet`.`name` = ? - Array
(ERROR in xPDO::connect @ /home/webuser/helloworld/htdocs/core/xpdo/xpdo.class.php : 318) SQLSTATE[HY000] [2002] Can’t connect to local MySQL server through socket ’/var/lib/mysql/mysql.sock’
эм.. если на сайте 30 страниц, требуется ли вообще отслеживать сессии???
Могу помочь оптимизировать вам сервер.
у тебя mysql сервак отваливается, поставь в настройках session_handler_class пустым (убери modSessionHandler) - будет использоваться стандартный механизм сессий php, включи кэширование по максимуму что можешь.
вообще интересная тема, отпишись пожалуйста, по результату.
Мдя.. даже на "авторизоваться в базе" не хватает.
Ставь nginx с кэшированием в качестве frontentd-а (вроде про него ничего в архитектуре не написано было). (он, кстати, неплохо нагрузку с Apache забирает, если статику через него отдавать). Страницы ведь не особо часто обновляются?
Или "переделывать" сайт (возможно, придется в архитектуру "погружаться") чтобы кэшированные страницы без mysql-соединения отображались...
По архитектуре MODx не подскажу.. ( Возможно, имеет смысл в англоязычный раздел запостить.. думаю, варианты должны быть)
* Одно время "оперативно" решить задачу удалось методом "простого" кэширования, который встраивается практически над любой CMS.
От URL страницы берем хэш-функцию (MD5, например) и ищем файл с таким именем в каталоге кэша. Если есть - выводим. Если нету - лезем в CMS за контентом и перед выводом в браузер "кэшируем" в этот файл. Логика очистки кэша и учета дополнительных данных (POST, COOKIE, SESSION) может быть самая разная... Но для "гостевых" пользователей (часто именно их больше всего) такая "фенька" позволяет заметно снизить нагрузку...
Естественно, решение "в чистом виде" подходит не для всех сайтов. Применялось в качестве временного не для MODx.
Удачи.