Тут зависит от размера проекта

Ну а как от размера проекта зависит что смски перестанут слаться, которые слались по ивентам?

Ну а как от размера проекта зависит что смски перестанут слаться, которые слались по ивентам?

Так какой смысл от данного удаления, если честно не очень понятно

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

Просто обычно все болт клали на ивенты, и просто дёргают руками кругом этот смс сервис и всё

Проблема удаления тут однозначно не главная

Но мы решаем ее )

Вы пишете код чтобы его удалить?

Проблем удаления тесно связана с темой loose coupling

Просто обычно все болт клали на ивенты, и просто дёргают руками кругом этот смс сервис и всё

ивенты тоже штука так себе: хер концы потом найдешь с непрямой диспетчеризацией. хер тест напишешь что гарантирует отправку смс когда ты чет купил

ивенты тоже штука так себе: хер концы потом найдешь с непрямой диспетчеризацией. хер тест напишешь что гарантирует отправку смс когда ты чет купил

Ну для тестов решения есть, от самых простых - синхронных дипатчей в тестах. До - задержки в тестах на время выполнения всего - но вот тесты усложняются, тесты становится писать бОлее влом

еще онбординг сильно усложняется: новый разраб в команде гарантированно будет не очень счастлив, разгребая общение основанное на ивентах

Апи платформ кстати на ивентах же вся

И дебажитл такое то ещё удовольствие

Хукт ивенты суть в том что код который что-то делает вызывается неявно

Плюс можно напортачить с приоритетом и отхватить баги которые тоже сложно обнаружить

Плюс можно напортачить с приоритетом и отхватить баги которые тоже сложно обнаружить

Был у меня кейс где они поменяли приоритет своего сериалайзера или что-то такое. И все сломалось

Они просто впихнули это в минорное обновление

Ну делайте просто норм семвер и норм ченджлог )

Короче если занимаешься оптимизацией прода, можно забить хер, как сказали выше - сервисы не участвуют в основном контейнере если на них нет ссылок. Если занимаешься оптимизацией разработки, так как сборка контейнера занимается время - можно попробовать поиграть с exclude и glob паттернами. Но и то не факт, что это даст профит, надо смотреть кишки, как там происходит проход по файлам. Короче по большей части не стоит того, если нет острой и главное понятной для себя необходимости. Ссылка на доку https://symfony.com/doc/current/service_container.html#importing-many-services-at-once-with-resource

а кеш локальный что ли (в файлах?)?

редис сам прекрасно кластеризуется. если на пальцах (это исключительно упрощенный пример), то он сам может собраться в определенный кластер, с дублированием, резервированием, разделением нагрузки, а вот приложение с ним работает будто это локальный сингл-инстанс базы на десятки терабайт

однопоточность плоха только если у тебя одна команда съедает много времени (сложные операции с линейной сложностью O(N) над огромными листами, долгие lua-скрипты и всё такое). тогда последующие за этой командой встают в очередь и долго ее ждут, это правда не очень приятно. но это довольно сложно сделать, используя редис как кеш. в остальном редис достаточно спокойно переживает 200-400 krps на среднем железе, несмотря на однопоточность

Спасибо, я читал про 80к+- на средненьком железе, а тут вон оно как. Но 200-400, все равно упираемся потом и надо уже делать распределнный кэш?

если у вас 200 тысяч запросов в секунду за кешем, то вам тем более обязательно надо идти в кластеризацию, хотя бы с целью распределения нагрузки по нескольким машинам, вы ходите в районе физического предела одной машины

и если упретесь в него, резко станет херово всему приложению. то есть если у вас условных 200 krps, и вы их параллелите, у вас сейчас N инстансов с такой нагрузкой. которые суммарно все равно пережевывают эти 200к. если их соединить в кластер, этот кластер на тех же ресурсах потянет условных 700к, при тех же затратах

с независимыми кешами легко себе представить, что какой-то воркер не получил команду (рестартился в этот момент, или еще что) и не сбросил кеш своего инстанса. и тогда запросы за одними данными будут отвечать разными ответами в зависимости от того, на какую ноду упал запрос, это же сущий кошмар, который замучаешься дебажить

А что насчет однопоточности, без вычислений в нее не упремся?

это "слышал звон, да не знаю где он" типа. не упретесь, я там выше накидал простую арифметику того, что вы и так упретесь в нее. типа сейчас вы параллелите абсолютно одинаковые запросы на каждый редис

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