boost::asio 线程池与 io_service_per_cpu 设计

boost::asio threadpool vs. io_service_per_cpu design(boost::asio 线程池与 io_service_per_cpu 设计)

本文介绍了boost::asio 线程池与 io_service_per_cpu 设计的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

目前我不确定,我尝试制作高性能服务器,我有一个 6Core CPU,所以如果我使用io_service_per_cpu"设计,我有 6 个 io_service.

Currently I´m not sure, I try to make a high-performance server, I got a 6Core CPU, so if I would use the "io_service_per_cpu" design, I have 6 io_service´s.

我已经听说线程池设计不是最好的,但我不确定.

I already heard that the threadpool design isn´t the best one, but I´m not sure about that.

你有什么知识?有人已经对每个人进行了压力测试,还是其他什么?

What knowledge do you have? Someone already made a Stress test with each, or something else?

推荐答案

根据我的经验,按照以下顺序进行异步应用程序设计要容易得多:

In my experience it is vastly easier to approach asynchronous application design with the following order:

  1. 单线程和一个io_service
  2. 多个线程,每个线程从单个 io_service 调用 io_service::run().使用 strands 作为处理程序需要访问共享数据结构.
  3. io_service 每个 cpu
  1. single thread and a single io_service
  2. multiple threads, each invoking io_service::run() from a single io_service. Use strands for handlers that require access to shared data structures.
  3. io_service per cpu

在对您的应用程序进行概要分析之后,应该考虑在这些设计中的每一个之间进行更改.请注意,仅 HTTP Server 2 示例展示了如何使用每个 CPU 的 io_service,它没有告诉你何时或为什么使用这样的设计.

The motivation for changing between each of these designs should be done after profiling your application. Note that the HTTP Server 2 example only shows how to use an io_service per CPU, it does not show you when or why to use such a design.

这篇关于boost::asio 线程池与 io_service_per_cpu 设计的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持编程学习网!

本文标题为:boost::asio 线程池与 io_service_per_cpu 设计

基础教程推荐