Интересно узнать,а нагружает ли composer как оверхед на сервер. При выборе хостинга у нас есть под рукой cms и все,а на vds можно всякие compose- ры,почтовики и все что вздумается. Я читал что,должен быть установлен композер если стоит фреймворк,но ведь можно и без композера установить. Композер делает автоподгрузку,и тут такой вопрос,он это делает асинхронно и это не влияет особо на сайт,или он каждый при каждом запросе к серверу генерит классы,и нагружает тем самым. Это я накрутил себе или есть такая нотка?
Конечно накручиваете. Если речь про подгрузку зависимостей в скрипт из Composer, то это просто по факту обычный require_once() перечисленных библиотек. Естественно это выполняется синхронно, поскольку это PHP. Если речь про сам компонент Composer как менеджер зависимостей, то он никакого никакого отношения к выполнению скриптов не имеет.
Бред вам рассказали, абсолютно никак он не влияет на производительность, это обычный пакетный менеджер для пхп. Пакетные менеджеры это инструменты для отслеживания зависимостей, их обновления, деплоя на сервер и т.д. К выполнению кода вообще отношения не имеет.
Вам правильно написали, что по-хорошему, с Композером надо работать на локальной машине.
Но, если будете гонять его на боевой машине, обязательно учтите, что Composer использует совершенно непотребное количество оперативной памяти (и автор отвечает на вопросы об этом, по сути, издёвками).
К примеру, для установки Drupal 8 или обновления одного установленного модуля вам едва-едва хватит гигабайта. Что-то более серьёзное может потребовать больше.
Так что я бы закладывал потребление RAM примерно 1-1.5 ГБ в моменты, когда Композер работает. Нагрузка на процессор тоже будет не нулевой, но она всё-таки много более сносная.
Zettabyte, dlakazov, не все так страшно, да, когда память свободна composer заберет ее под свои нужды. Просто, чем больше памяти в его распоряжении, тем он быстрее отработает. Так что вам совсем не нужно 1-1.5Гб памяти на установку Drupal8, хватит и 250Мб, просто composer будет работать раза в 2 медленее.
вам совсем не нужно 1-1.5Гб памяти на установку Drupal 8, хватит и 250Мб
Вы, должно быть, шутите?
Сколько раз вы устанавливали Друпал 8 с нуля, используя Композер? Когда вы это делали в последний раз? Какой из трёх способов использовали?
На всякий случай, я очень хорошо знаю, что говорю.
Настолько хорошо, что когда об этом заходит речь, каждый раз готов практически орать и обкладывать соответствующими органами разработчика Composer'а.
Zettabyte, устанавливал после того, как прочитал ваш комментарий, специально оставив свободными только 250Мб памяти.
Если опишите условия, при которых не хватит 250Мб, обязательно попробую.
Одна из проблем с композером, с которой я столкнулся, была в том, что он игнорировал абсолютно любые попытки ограничить ему использование памяти.
Только с этим сидел, по-моему, не меньше вечера - и отдельный php.ini и передача через параметры запуска и переменная окружения и установка лимита на весь аккаунт - всё шло мимо. Пробовал варианты с оф. сайта, stackoverflow, drupal.org - без толку.
За примерами далеко ходить не надо, хотя на большинстве сайтов рекомендуют выставить memory_limit = -1, а гайд на Друпал.орг начинается совершенно шикарно: "Troubleshooting Composer can be frustrating": https://www.drupal.org/docs/develop/using-composer...
Композер - это менеджер зависимостей, которые устанавливаются на сайт. На этом его работа закончена. На нагрузку компа он никак не влияет, так как не запущен.
Разово запустить может только разработчик для установки либо обновления зависимостей.
Композер не нагружает сервер. И никакой "автоподгрузки" он не делает.
На продакшене его быть не должно. Как и системы контроля версий.
На продакшен должен выкладываться только код.
Stalker_RED, Я добавил функционал в проект (Локально). Подтянул новый компонент через composer. Протестировал, закоммитил изменения в репозиторий.
Какие дальнейшие мои действия чтобы изменения оказались на продакшене (в ваших терминах)?
BD_ l3ftoverZ!, автозагрузчик делается 1 раз при вызове composer update/install. При этом все библиотеки подтягиваются сразу. Никакой автоподгрузки на лету, о которой грезит автор, в композере нету.
Да, на сервер заливать проект с кучей зависимостей. Это, кстати, на порядки быстрее, чем обновлять композером, кстати о птичках
FanatPHP, то есть сам процесс юзания,php то сам не может подключать,композер делает за него,и я хотел это узнать он на уровне файлов собирает или на уровне скрипта php то слушает постоянно когда хотят подключится
Что?! Недолжно быть контроля версий? Серьезно? Может вы просто не умеет готовить деплой?
Контроль версий должен быть, но ключ сервера должен иметь read-only доступ, чтоб не давать соблазна коммитить или как-то модифицировать код на сервере. Алгоритм деплоя где-то такой:
Скрипт переводит сервис в MaintenanceMode, на всякий случай убиваются локальные изменения, если их вдруг кто-то набыдлячил. Конфигурационные файлы с доступами должны быть добавленны в ignore, во первых это исключает что их кто-то зальет на какой-то github, а во вторых что они не будут снесены как локальные изменения. Дальше подтягивает из контроля версий актуальную версию, включающую composer.lock, и делает composer install. Восстанавливаем работу сервиса(если нужно что-то перезапустить или обнулить), убираем заглушку MaintenanceMode и радуемся жизни.
Жду от вас аргументации, что в этой схеме изьян.
P.S. dlakazov, composer оптимизирует autoloader, так что в некоторых случаях, это может даже ускорить подключение скриптов и избавит вас от рутинной работы и облегчит обновление версий
kruslan, Зависит от логики изменений. Иногда изменения довольно значительные и нужно либо ограничить пользователей в использовании системы на время обновления, либо постепенно мигрировать в случае непрерывного потока пользователей. Как пример пользователи каждую секунду загружают файлы какие-то в систему, или идёт переход на другую базу которая наполняется непрерывно. Тут либо ограничить пользователей и заставить их подождать, либо делать хитрую репликацию с чтением и записью паралельной
BD_ l3ftoverZ!, мне скучно разговарить с людьми, которые не прилагают должных усилий к прочтению чужих реплик, и из-за этого приходится им повторять по два раза.
Композером библиотеки подтягиваются на деве/стейджинге. На продакшен все едет блобом. Это не только азы безопасности, но, как я уже говорил, и на порядки быстрее.
Тут все споры от того, что люди в разных мирах крутятся.
На большом проекте, там где более 1
app-сервера, никто не использует выкатку через git, или заглушку с простоем сайта. Там есть несколько окружений (обычно это dev, staging, prod). Dev - локальная среда разработки, staging - тестовый сервер, prod - боевой сервер. код и все зависимости должны быть одинаковые. Поэтому CI/CD, doker, k8s и вот это вот всё..
С другой стороны - ребята, которые делают не сильно нагруженные сайты. Где не критичен простой. Где важно быстрее фичу доставить. О каком деплое тут может идти речь? В крупных компаниях на систему CI/CD угрохано несколько человеко-лет разработки.
Отсюда и всё непонимание. Почему деплой - это не руками набрал git pull, а запуск по кнопке в bamboo, teamcity или gitlab
Средний
Простой
Средний
