我经历了一些问题，例如多处理器系统上的POSIX 线程和多处理器机器中 posix 线程的并发性以及线程和进程与多线程和多核/多处理器：它们是如何映射的？
基于这些和其他一些 Wiki 文章，我相信对于具有三个基本工作的系统，即输入、处理和输出
对于 CPU 密集型线程的 CPU 绑定处理数量（应用程序数量 * 每个应用程序的线程数）应该是处理器内核数量的 1 到 1.5 倍。
输入和输出线程必须足够大，以消除任何瓶颈。例如对于基于query/query-ack和response/response-ack模型的通信系统，时间不能浪费在I/O等待状态。
如果对动态内存的需求很大，最好使用更多的进程而不是线程（以避免内存同步）。
在确定我们的应用程序中的线程数时，这些参数是否相当一致？我们是否需要查看任何其他参数？
“核心数量的 1 到 1.5 倍” - 这似乎取决于操作系统/语言。例如，在 Windows/C++ 上，对于大量 CPU 密集型任务，最佳值似乎是内核数量的两倍多，而性能分布非常小。如果是这样的环境，您似乎还不如在一个池上分配 64 个线程，而不用担心内核数量。
'query/query-ack 和 response/response - ack 模型，时间不能浪费在 I/O 等待状态' - 对于大多数网络具有高延迟的此类协议，这是不可避免的。延迟是由“乒乓”协议强制执行的，因此不可避免地会有 I/O 等待。异步 I/O 只是将此等待移入内核 - 它仍然存在！
'对动态内存的大量要求，最好使用更多的进程而不是线程' - 不是真的。“对动态内存的大量需求”通常意味着要移动大数据缓冲区。大缓冲区只能通过引用有效地移动。由于共享内存空间，这在线程之间非常容易和快速。对于进程，您会陷入尴尬且缓慢的进程间通信。
“确定我们的应用程序中的线程数”——嗯，在几个方面都很难。给定一个未知的架构，设计。语言和操作系统，我唯一的建议是尽量让一切都尽可能灵活和可配置。如果您有一个线程池，请将其大小设置为您可以调整的运行时参数。如果您有对象池，请尝试对其进行设计，以便可以更改其深度。有一些适用于您的测试盒的默认值，然后，在安装或运行时，您可以对特定系统进行任何特定的更改和调整。
灵活/可配置设计的另一件事是，您可以在测试时调整并修复建筑师、设计师、开发人员以及最重要的是客户做出的许多错误决策、假设和猜测