В
норм, решение
вот только непонятно определение "средненькая машина"
вот только непонятно определение "средненькая машина"
Допустим i7-4790K 4 ядра 8 потоков 4гц. На какую 10^x степень клиентов ориентироваться
Size: a a a
2020 July 16
С
Зависит от логики обработки запросов. Больше ~65к одновременных соединений всё равно не установить - порты закончатся
В
Спасибо за ответы, начинаю развлекаться с акторами)
A
Зависит от логики обработки запросов. Больше ~65к одновременных соединений всё равно не установить - порты закончатся
в одну машнку можно не одну сетевую карту вставить и ограничение спадет 😄
AV
Добрый день, только начал изучать актикс и асинхроншину в расте и есть небольшие вопросы. Для каждого пользователя у меня должнать быть очередь запросов и ssl соединение с третьей стороной с использованием сертификата пользователя, планирую сделать это с помощью акторов, под каждого пользователя при запросе создавать актора(если не существует), который будет держать ссл и обрабатывать очередь(~3 запросов в секунду), как только очередь кончилась убивать актора. Интересует насколько это адекватное решение и сколько примерно экземпляров акторов можно создать на средненькой машине(100, 1000, 10000)?
Зачем акторы когда есть tokio::spawn....
В
Зачем акторы когда есть tokio::spawn....
Пишу на актикс_веб сервис и акторы первое что пришло в голову, с токио еще толком не разбирался
AV
Лучше пиши сразу на токио
AV
Как минимум будет меньше проблем с интеграцией асинхронных библиотек
AV
+ возможно что акторы не нужны когда есть структурированная конкурентность
В
Лучше пиши сразу на токио
Хорошо, попробую разобраться с токио. Довольно сложно мне дается асинхронщина и тд в расте. Начну пожалуй с статьи Hirrolot, только сейчас заметил, что он ее уже выпустил)
PL
Зачем акторы когда есть tokio::spawn....
Ну тогда уж spawn+очереди. Потому как актор это всегда mailbox + логика для обработки сообщений. Просто в случае с actix это "пассивные" акторы (пишешь только функции-обработчики, сложно интегрировать таймеры/io, зато выглядит аккуратнее), а в случае с явным spawn+очереди это "активные" акторы (нужно самому написать loop, зато проще интегрировать сюда таймеры/io).
PL
Мне вот не хватает actix, но поверх threaded scheduler. Всё же чаще всего руками раскидывать акторы по арбитрам — оверхед на разбраотчике
AV
Ну тогда уж spawn+очереди. Потому как актор это всегда mailbox + логика для обработки сообщений. Просто в случае с actix это "пассивные" акторы (пишешь только функции-обработчики, сложно интегрировать таймеры/io, зато выглядит аккуратнее), а в случае с явным spawn+очереди это "активные" акторы (нужно самому написать loop, зато проще интегрировать сюда таймеры/io).
Чем mailbox лучше ограниченной очереди?
PL
Чем mailbox лучше ограниченной очереди?
Не понял? mailbox и есть (не)ограниченная очередь
AV
Я про tokio::sync::mpsc
PL
mailbox может быть поверх этой очереди реализован
PL
Мы же про архитектурный подход.
Либо ты пишешь
Либо ты пишешь
struct Kek { .. }
impl Actor for Kek
impl Handler<..> for Kek { /* LOGIC */ }
Либо ты пишешьstruct Kek { .. }
impl Kek {
pub async fn run(self, input: Receiver<..>) {
loop {
let msg = input.recv().await;
/* LOGIC */
}
}
}PL
Ещё есть подход с описанием актора как redux-like стора и редьюсера. Но в расте не видел реализаций. В целом, это разновидность первого варианта
2020 July 21
AT
Carl Lerche at 9:54 PM:
We released a new website w/ new guides! https://tokio.rs/ I would love feedback. Feel free to open issues on the repo: https://github.com/tokio-rs/website
We released a new website w/ new guides! https://tokio.rs/ I would love feedback. Feel free to open issues on the repo: https://github.com/tokio-rs/website
YJ
Carl Lerche at 9:54 PM:
We released a new website w/ new guides! https://tokio.rs/ I would love feedback. Feel free to open issues on the repo: https://github.com/tokio-rs/website
We released a new website w/ new guides! https://tokio.rs/ I would love feedback. Feel free to open issues on the repo: https://github.com/tokio-rs/website
👍🏻