我怎样才能让 Future Producer 在 rust rdkafka 中至少表现出 Threaded Producer 的性能?
How can I make FutureProducer to perform at least near the performance of ThreadedProducer in rust rdkafka?
我只是在玩弄这些示例,我尝试将 FutureProducer 与 Tokio::spawn 一起使用,并且每次生成大约需要 11 毫秒。
11000 毫秒(11 秒)内 1000 条消息。
虽然 ThreadedProducer 在大约 4.5 秒(开发)和 2.6 秒(--release)中产生了 1000000(100 万条消息)!!!,这是两者之间的疯狂差异,也许我错过了什么,或者我我做的不好。
如果存在这么大的速度差异,为什么还要使用 FutureProducer?
也许有人可以阐明让我了解和了解 FutureProducer。
Kafka 主题名称是“my-topic”,它有 3 个分区。
也许我的代码没有以合适的方式编写(对于未来的生产者),我需要使用 FutureProducer 在不到 10 秒的时间内生产 1000000 条消息。
我的尝试写在以下要点中(我更新了这个问题以添加新的要点)
注:
在我写下我的问题后,我尝试通过添加不同的想法来解决我的问题,直到我在第 7 次尝试中成功
1- 生成阻塞:
https://gist.github.com/arkanmgerges/cf1e43ce0b819ebdd1b383d6b51bb049
2-线程生产者
https://gist.github.com/arkanmgerges/15011348ef3f169226f9a47db78c48bd
3- 未来的制作人
https://gist.github.com/arkanmgerges/181623f380d05d07086398385609e82e
4-os 个线程与基础生产者
https://gist.github.com/arkanmgerges/1e953207d5a46d15754d58f17f573914
5- os 与未来制作人的话题
https://gist.github.com/arkanmgerges/2f0bb4ac67d91af0d8519e262caed52d
6- os 线程,为未来的生产者生成了 tokio 任务
https://gist.github.com/arkanmgerges/7c696fef6b397b9235564f1266443726
7- tokio 多线程使用#[tokio::main] 和 FutureProducer
https://gist.github.com/arkanmgerges/24e1a1831d62f9c5e079ee06e96a6329
在我的第 5 个示例中,我需要使用 os 线程(感谢与@BlackBeans 的讨论),并且在 os 线程中我使用了使用 4 个工作线程的 tokio 运行时并且它将在 os 线程中阻塞。
该示例使用了 100 个 os 线程,每个线程都有带 4 个工作线程的 tokio 运行时。
每个 os 线程将产生 10000 条消息。
代码未优化,我 运行 在构建开发中。
我在第 7 次尝试中完成的一个新示例,我使用 #[tokio::main] 默认情况下将使用 block_on,当我生成一个新任务时,它可以是在主调度程序(在 block_on 内)下放入一个新的 os 线程(我已经使用 #[tokio::main] 进行了单独的测试来检查它)。并且可以在 2.93 秒(开发构建)和 2.29 秒(发布构建)中生成 100 万条消息
我只是在玩弄这些示例,我尝试将 FutureProducer 与 Tokio::spawn 一起使用,并且每次生成大约需要 11 毫秒。 11000 毫秒(11 秒)内 1000 条消息。
虽然 ThreadedProducer 在大约 4.5 秒(开发)和 2.6 秒(--release)中产生了 1000000(100 万条消息)!!!,这是两者之间的疯狂差异,也许我错过了什么,或者我我做的不好。 如果存在这么大的速度差异,为什么还要使用 FutureProducer? 也许有人可以阐明让我了解和了解 FutureProducer。
Kafka 主题名称是“my-topic”,它有 3 个分区。
也许我的代码没有以合适的方式编写(对于未来的生产者),我需要使用 FutureProducer 在不到 10 秒的时间内生产 1000000 条消息。
我的尝试写在以下要点中(我更新了这个问题以添加新的要点)
注: 在我写下我的问题后,我尝试通过添加不同的想法来解决我的问题,直到我在第 7 次尝试中成功
1- 生成阻塞: https://gist.github.com/arkanmgerges/cf1e43ce0b819ebdd1b383d6b51bb049
2-线程生产者 https://gist.github.com/arkanmgerges/15011348ef3f169226f9a47db78c48bd
3- 未来的制作人 https://gist.github.com/arkanmgerges/181623f380d05d07086398385609e82e
4-os 个线程与基础生产者 https://gist.github.com/arkanmgerges/1e953207d5a46d15754d58f17f573914
5- os 与未来制作人的话题 https://gist.github.com/arkanmgerges/2f0bb4ac67d91af0d8519e262caed52d
6- os 线程,为未来的生产者生成了 tokio 任务 https://gist.github.com/arkanmgerges/7c696fef6b397b9235564f1266443726
7- tokio 多线程使用#[tokio::main] 和 FutureProducer https://gist.github.com/arkanmgerges/24e1a1831d62f9c5e079ee06e96a6329
在我的第 5 个示例中,我需要使用 os 线程(感谢与@BlackBeans 的讨论),并且在 os 线程中我使用了使用 4 个工作线程的 tokio 运行时并且它将在 os 线程中阻塞。 该示例使用了 100 个 os 线程,每个线程都有带 4 个工作线程的 tokio 运行时。
每个 os 线程将产生 10000 条消息。 代码未优化,我 运行 在构建开发中。
我在第 7 次尝试中完成的一个新示例,我使用 #[tokio::main] 默认情况下将使用 block_on,当我生成一个新任务时,它可以是在主调度程序(在 block_on 内)下放入一个新的 os 线程(我已经使用 #[tokio::main] 进行了单独的测试来检查它)。并且可以在 2.93 秒(开发构建)和 2.29 秒(发布构建)中生成 100 万条消息