Всем привет! Как всегда одни советуют поменять хостинг другие использовать костыли или скрипты. Это конечно иногда имеет определённые нюансы, но не в той мере, чтобы особо влиять на производительность сервера. Вот что надо понимать:
Желательно использовать VDS, рекомендовать провайдера не буду, “всяк кулик своё болото хвалит”, кому интересно, где хостюсь я, пишите в личку.
VDS сервера, как правило разворачивают из готовых образов OS Linux (я использую Debian), причём эти образы, рассчитаны на любую конфигурацию сервера хостера. Вот здесь первый подвох, без грамотной настройки всех серверных и прикладных пакетов, оптимизации работы не добиться. Если не понимаете в этом, грамотному специалисту придётся заплатить, в зависимости от типа настройки от 15 до 30 кило рублей, если сервер не новый, а уже в проме, цена будет выше. Присутствие панели управления ISP Manager тоже желательно.
CS-CART, да и в принципе любую CMS лучше поднимать на связке NGINX + PHP-FPM. Здесь тоже есть пару подводных камней, первый - это предоставленный пример конфигурационного файла NGINX, если копи-пастить, скорее всего не включиться модуль для SEO ссылок и не будет штатно работать обновление. Если модуль можно тупо включить в базе и он вроде как работает без ошибок, то с обновлениями надо править файл ядра, а после обновления отменять изменения. Второй - это привязка SSL, в связи с тем, что конфигурация CS-CART и так замудрённая, с SSL под NGINX тоже есть свои нюансы. На крайнем проекте времени для тренировок было больше, по этому кашерный конфиг для NGINX имеется (OS Debian 9 + ISP Manager).
Всё что необходимо CS-CART для установки он и так запросит при проверки системы во время инсталляции, главное установить и настроить.
Кастомизация шаблона или создание своего, разработка модулей и другие работы в частности программирования, не забывайте и об этом. Нативность при разработке это очень хорошо, только в случае готовых решений она должна быть направлена не в сторону языка, а в сторону спецификаций решения (в нашем случае CMS).
Ещё как рекомендация, периодически вычищайте таблицу логов, растёт довольно быстро при хорошей посещаемости.
На конфигурации VDS - 3 ядра CPU, 3 GB RAM, 40 GB Disk, ∞ 100 Мбит/c, OS Debian 9 - полёт нормальный!!!
Настройка сервера зависит в первую очередь от масштабов проекта, установленных модулей, корректности написания кода. Общие рекомендации которые прозвучали достаточно субъективны. Одному проекту достаточно 3х ядер некоторым не хватает и 72. Относительно redis хочу предупредить что под реальной нагрузкой ведет себя достаточно скверно, а во время сбрасывания на диск вообще создает крупные проблемы. Так же с tmpfs - это конечно хороший костыль когда все работает корректно и у вас полно свободной оперативной памяти, но на деле бывают косяки и это создаст вам крупные неприятности. В общем не ищите легких путей и решений, все надо тестировать и здраво оценивать какие технологии вам подходят, используйте тестирующее ПО для того чтобы оценить разницу в производительности, научитесь пользоваться дебагером который сильно упрощает настройку. Либо же просто предоставьте это дело людям которые занимаются настройкой на профессиональном уровне и дадут все нужные рекомендации.
Редис штука отличная, тут вопрос даже не в сбросе на диск - дело в том, что коробочная работа с сессиями слишком проста.
У нас на 40-50к уников сутки редис вообще ничего не занимал, сброс на диск был незаметен.
Проблема в сроке жизни сессий - большие нагрузки такого отношения не терпят, например сессии без корзин должны жить 12 часов после визита, сессии с корзинами - можно и месяц. Таких нюансов наберется десяток и в итоге для посещаемого ресурса редис ест 200mb и потребляет минимум ресурсов.
Если у CS Cart включить редис для сессий, то он хранит по-умолчанию корзины с закладками два часа, после чего чистит их. Этот момент не указан в документации; так же не указано, какую строку и где надо поменять, чтоб увеличить ttl сессий для редиса.
А если найти настройку в коде и увеличить, например, до 14 дней – будут две недели храниться мусорные сессии с пустыми корзинами и сессиями ботов, а это уже сотни тысяч ключей.
Это все к тому, что у CS Cart внедрена возможность использовать редис для галочки, и надо переписывать ядро, чтоб он не перегружался.
Это единственно правильное поведение. Но даже им следует дать указания с требованиями той или иной CMS, особенно если две разные на одном сервере, одна из которых не будет работать под IONCUBE 10 и MySQL 5.7, a на cPanel downgrade to 5.6 никак не сделаешь.
Куда можно обратиться по проблемам в playbook? У меня сбоит на последнем шаге 3, запуск плейбука.
Не говорю уж о паре других проблем, которые удалось нагуглить.
sudo yum update -y nss curl libcurl
и yum install не запускался без --disablerepo=epel
С такими вопросами быстрее всего может помочь поддержка. При обращении в Help Desk у нас больше возможностей, чем на форуме, чтобы воспроизвести и решить проблему.
Прошу уточнить свежие настройки окружения есть? Там где будет настройки php 8.1. Возможность установки на ubuntu 22.04 или других свежих версий линукса.