R
а какие гарантии есть?если мы этому параметру присваиваем значение 1, например
Size: a a a
2020 November 19
R
ну или 100, как на скриншоте
R
вот это закомменченное объяснение все равно оставило вопросы
Oℕ
это нужно трактовать "максимально количество сообщений, которое обработается синхронно, если в очереди есть не меньше этого количества"
т.е. это настройка производительности, если актор очень быстро работает, вам выгоднее это число побольше поставить, чтобы меньше было оверхеда на переключение
а если актор долго работу делает, лучше поставить поменьше, чтобы толстые акторы не тормозили систему
т.е. это настройка производительности, если актор очень быстро работает, вам выгоднее это число побольше поставить, чтобы меньше было оверхеда на переключение
а если актор долго работу делает, лучше поставить поменьше, чтобы толстые акторы не тормозили систему
NG
возможно, что отмена происходит где-то в конце, когда тест завершается, и пока один из стримов уже отменён, фс2 успевает ещё один запустить
Хм
А это интересно
Спасибо, я попробую
А это интересно
Спасибо, я попробую
withPermit)Oℕ
это нужно трактовать "максимально количество сообщений, которое обработается синхронно, если в очереди есть не меньше этого количества"
т.е. это настройка производительности, если актор очень быстро работает, вам выгоднее это число побольше поставить, чтобы меньше было оверхеда на переключение
а если актор долго работу делает, лучше поставить поменьше, чтобы толстые акторы не тормозили систему
т.е. это настройка производительности, если актор очень быстро работает, вам выгоднее это число побольше поставить, чтобы меньше было оверхеда на переключение
а если актор долго работу делает, лучше поставить поменьше, чтобы толстые акторы не тормозили систему
считайте это примерным аналогом batchSize \ chunkSize в потоковой обработке
R
это нужно трактовать "максимально количество сообщений, которое обработается синхронно, если в очереди есть не меньше этого количества"
т.е. это настройка производительности, если актор очень быстро работает, вам выгоднее это число побольше поставить, чтобы меньше было оверхеда на переключение
а если актор долго работу делает, лучше поставить поменьше, чтобы толстые акторы не тормозили систему
т.е. это настройка производительности, если актор очень быстро работает, вам выгоднее это число побольше поставить, чтобы меньше было оверхеда на переключение
а если актор долго работу делает, лучше поставить поменьше, чтобы толстые акторы не тормозили систему
то есть это количество обновляется где-то в памяти потока после каждого переключения?
Oℕ
настройка не обновляется
работает примерно так
def processActor() = {
val messages = mailBox.take(throughput)
for (m, sender) <- messages
actor.receive(m)(sender)
}
работает примерно так
def processActor() = {
val messages = mailBox.take(throughput)
for (m, sender) <- messages
actor.receive(m)(sender)
}
R
мм
Oℕ
т.е. когда переключается на новый актор, попытается прочитать из очереди throughput сообщений или меньше и обработать их в один присест
R
т.е. когда переключается на новый актор, попытается прочитать из очереди throughput сообщений или меньше и обработать их в один присест
после этого поток переключится на актор, в мэйлбокс которого сообщения пришли раньше?
R
настройка не обновляется
работает примерно так
def processActor() = {
val messages = mailBox.take(throughput)
for (m, sender) <- messages
actor.receive(m)(sender)
}
работает примерно так
def processActor() = {
val messages = mailBox.take(throughput)
for (m, sender) <- messages
actor.receive(m)(sender)
}
один поток например. два актора. throughput = 100
пока актор А обрабатывал 100 сообщений, актору Б и самому актору А пришло ещё по 100.
куда пойдёт поток?
пока актор А обрабатывал 100 сообщений, актору Б и самому актору А пришло ещё по 100.
куда пойдёт поток?
R
настройка не обновляется
работает примерно так
def processActor() = {
val messages = mailBox.take(throughput)
for (m, sender) <- messages
actor.receive(m)(sender)
}
работает примерно так
def processActor() = {
val messages = mailBox.take(throughput)
for (m, sender) <- messages
actor.receive(m)(sender)
}
а так вот это понятно, спасибо
R
ещё вот этих трёх параметров нет в оф. документации ThreadPoolExecutor
кто знает чему они соответствуют в классе ThreadPoolExecutor?
скриншот взялся с этой страницы доки акки
кто знает чему они соответствуют в классе ThreadPoolExecutor?
скриншот взялся с этой страницы доки акки
Oℕ
RAFIZ
после этого поток переключится на актор, в мэйлбокс которого сообщения пришли раньше?
да неизвестно, куда потом тред уйдёт
Oℕ
RAFIZ
один поток например. два актора. throughput = 100
пока актор А обрабатывал 100 сообщений, актору Б и самому актору А пришло ещё по 100.
куда пойдёт поток?
пока актор А обрабатывал 100 сообщений, актору Б и самому актору А пришло ещё по 100.
куда пойдёт поток?
неизвестно
NG
возможно, что отмена происходит где-то в конце, когда тест завершается, и пока один из стримов уже отменён, фс2 успевает ещё один запустить
Олег, эта версия подтвердилась:
Я поменял семафор на очередь, чтобы избавиться от прерывания осноного стрима (pipeline.analyze) и в общем-то логи говорят сами за себя:
fs2 успевает еще один сабстрим запустить во время завершения основного стрима
Я поменял семафор на очередь, чтобы избавиться от прерывания осноного стрима (pipeline.analyze) и в общем-то логи говорят сами за себя:
- putToQueue
- putToQueue
- putToQueue
- putToQueue
- It's done
- putToQueue
fs2 успевает еще один сабстрим запустить во время завершения основного стрима
NG
возможно, что отмена происходит где-то в конце, когда тест завершается, и пока один из стримов уже отменён, фс2 успевает ещё один запустить
NG
возможно, что отмена происходит где-то в конце, когда тест завершается, и пока один из стримов уже отменён, фс2 успевает ещё один запустить
Oℕ
Олег, эта версия подтвердилась:
Я поменял семафор на очередь, чтобы избавиться от прерывания осноного стрима (pipeline.analyze) и в общем-то логи говорят сами за себя:
fs2 успевает еще один сабстрим запустить во время завершения основного стрима
Я поменял семафор на очередь, чтобы избавиться от прерывания осноного стрима (pipeline.analyze) и в общем-то логи говорят сами за себя:
- putToQueue
- putToQueue
- putToQueue
- putToQueue
- It's done
- putToQueue
fs2 успевает еще один сабстрим запустить во время завершения основного стрима
предположу, что у вас cats.effect.IO