ну вот потому и вопрос был по оверхеду самого сбора хэша )

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

кмк, не стоит
всё равно потом дополнительно фильтровать придётся скорее всего.
плюс с блэклистом отдельная морока - его нужно будет поддерживать в актуальном состоянии.

это да, если иметь ввиду горячие функции, но для вендорского кода все-таки актуальность легко держать, по маске пути, например )

Всем привет. Мы мерили после балансера, все так. Отдельно не мерили потому что хотелось реальных цифр, а не синтетики. В докладе был слайд как идёт просадка по rps когда включили всего на 1 машине на 100 процентов. Проблем по памяти особо не заметили на наших кластерах в нашей нагрузке на нашем жедезе, не факт что на другом проекте будет по другому. Балансер учитывает нагрузку на cpu. Значит просадка по rps и cpu должны коррелировать. Графиков прямо сейчас под рукой нет, увы, с мобилы в отпуске :( если нужно то отеопаю и пришлю позже, дайте знать в личку

Все просто. Картинка была позаимстаована отсюда http://www.phpinternalsbook.com/php7/extensions_design/php_lifecycle.html :)

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

Дай плиз ссылки сами и страницу где они были. Поправим эту оплошность

Если на что-то ещё не ответил, то велком в личку ;)

Спасибо большое )))

а ссылок на материалы нет тут (https://tech.badoo.com/ru/article/815/chto-delat-s-legacy/) под красивой кнопкой "Оригинал и комментарии на хабре" )))))

пофиксили, спс))

Нзч)))

Всем привет. Немного офтоп))

Делаю сервис уведомлений. В нем три канала доставки: смс, почта, в сервис.

Всё вроде бы шло хорошо. Сделал каналы, типы уведомлений, подписчиков. Как дошло дело до проектирования отправки и шаблонов писем, то немного зашёл в ступор... У меня есть сейчас система рассылки сообщений в ней тоже есть каналы рассылки: смс и маил. Шаблоны писем.

Вопросы:
1. Стоит ли проектировать в системе уведомлений реализацию отправки сообщений по каналам, шаблоны писем, не смотря на то, что они уже есть такие же в системе рассылки? Либо мне из системы уведомлений просто передавать в систему рассылки?
2.  Может быть объединить эти два сервиса, раз они так тесно связаны?

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

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

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

То есть рассылки были более емкие и целенаправленные.  А уведомления чаще краткие и простые.

Когда была одна рассылка проблем не было. Как стали делать уведомления какой-то ступор в проектировании стал.

Кажется, что тут есть небольшая матрица возможностей:
1) транспорт доставки сообщений:
- смс
- email
- апи
2) функциональность:
- маркетинговые разовые рассылки
- служебные события

Кажется, что их нужно отделить друг от друга.

Первый пункт по сути - фабрика.
по второму пункту нужно больше контекста в бизнес требования, но кажется, что это не очень связанные функциональности.
Тут бы посмотреть, как планируется администрировать их, как собирать с них аналитику и статистику. И тд.

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

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

Отвечая на вопросы:

1) я бы выделил транспорт в отдельный слой абстракции. И ему было бы все равно, откуда приходили данные для отправки.  При этом была бы только одна точка ответственности за транспорт.

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

Я как раз делаю по DDD. Соотвественно контексты разные. Задачи по сути разные. С одной строны идут оповещения от площадки, а с другой стороны от группы людей. Даже заучит странно запланировать рассылку в системе уведомлений. И по факту и статистика другая, аналитика и так далее.

Полагаю, что Вы правильно разделили на события/оповещения системы и маркетинговые рассылки. Наверное, так оно и есть.