К сожалению в современном мире 2к пользователей это нагрузка уровня домашнего железа. Если вы хотите использовать это решение для более массовой аудитории есть большая вероятность столкнуться с серьёзными проблемами производительности. Мой комментарий в основном касался некоторых (на мой взгляд) странных решений, по типу необходимости персистеностного хранилища для реализаций серверов (локальный диск). Стейтфул парадигма для такого рода сервисов приводит к проблемам масштабирования. Пока что ковыряюсь в поисках возможности вынести все что связано с хранилищем полностью снаружи моего сервера.
Во первых спасибо за статью. Во вторых, складывается впечатление что в какой-то момент вам не хватило опыта или упорства раскатить данный проект хотя бы в docker. От себя дополню что на данный момент внутри протокола Matrix и его экосистемы существуют глобальные проблемы, связанные с отсутствием адекватной раскатки на действительно продовых сценариях. В особенности отмечу бедность k8s чартов, а также отсутствие адаптации к горизонтальному масштабированию. Оставшиеся реализации серверной части разочаровывают ещё больше чем тот же Synapse.
Про "тяжеловесно" соглашусь, но тут в игру вступает complexity биндингов, где вам нужно учитывать все возможные преобразования (например slice->tuple) что увеличивает когнитивную нагрузку для разработчика. Есть несколько статей и переводов где люди пытаются подружить rust + go достаточно сложным способом в link time. В общем случае если есть возможность принебречь временем потраченным на сериализацию вызова, то данный подход способен дать доступ к вызову метода в другом языке (python) из основного рантайма с минимальным complexity для продукта/проекта. В вопросе смены os thred'a действительно не было проведено тестирование поведения python, что действительно является минусом приведенной выше библиотеки. А по поводу версии и экземпляров интерпретатора все зависит от задачи, за частую в prod окружении версия будет зафиксирована (т.е. можно собираться только для одной), а количество используемых интерпретаторов ограничено только тем как вы организуете свой код внутри go runtime.
К сожалению в современном мире 2к пользователей это нагрузка уровня домашнего железа. Если вы хотите использовать это решение для более массовой аудитории есть большая вероятность столкнуться с серьёзными проблемами производительности. Мой комментарий в основном касался некоторых (на мой взгляд) странных решений, по типу необходимости персистеностного хранилища для реализаций серверов (локальный диск). Стейтфул парадигма для такого рода сервисов приводит к проблемам масштабирования. Пока что ковыряюсь в поисках возможности вынести все что связано с хранилищем полностью снаружи моего сервера.
Во первых спасибо за статью. Во вторых, складывается впечатление что в какой-то момент вам не хватило опыта или упорства раскатить данный проект хотя бы в docker. От себя дополню что на данный момент внутри протокола Matrix и его экосистемы существуют глобальные проблемы, связанные с отсутствием адекватной раскатки на действительно продовых сценариях. В особенности отмечу бедность k8s чартов, а также отсутствие адаптации к горизонтальному масштабированию. Оставшиеся реализации серверной части разочаровывают ещё больше чем тот же Synapse.
Про "тяжеловесно" соглашусь, но тут в игру вступает complexity биндингов, где вам нужно учитывать все возможные преобразования (например slice->tuple) что увеличивает когнитивную нагрузку для разработчика. Есть несколько статей и переводов где люди пытаются подружить rust + go достаточно сложным способом в link time. В общем случае если есть возможность принебречь временем потраченным на сериализацию вызова, то данный подход способен дать доступ к вызову метода в другом языке (python) из основного рантайма с минимальным complexity для продукта/проекта. В вопросе смены os thred'a действительно не было проведено тестирование поведения python, что действительно является минусом приведенной выше библиотеки. А по поводу версии и экземпляров интерпретатора все зависит от задачи, за частую в prod окружении версия будет зафиксирована (т.е. можно собираться только для одной), а количество используемых интерпретаторов ограничено только тем как вы организуете свой код внутри go runtime.
Для тех кому интересна тема использования python from go, можете оценить мой подход https://github.com/yaroher/gopybuf