我经历了一些问题，例如POSIX Threads on a Multiprocessor System和Concurrency of posix threads in multiprocessor machine以及Threads & Processes Vs MultiThreading & Multi-Core/MultiProcessor : How they are mapped?
基于这些和其他几篇维基文章，我相信一个系统有三个基本工作，即输入，处理和输出
对于CPU密集处理的CPU密集型线程数（应用程序数*每个应用程序的线程数），应该是处理器核心数的1到1.5倍。
输入和输出线程必须足够大，以便消除任何瓶颈。例如，对于基于query / query-ack和响应/响应-ack模型的通信系统，时间不得浪费在I / O等待状态中。
如果对动态内存有很大的要求，最好使用比线程更多的进程（以避免内存同步）。
在确定应用程序中的线程数时，这些参数是否相当一致？我们是否需要调查其他任何参数？
答案 0 :(得分：1)
'核心数的1到1.5倍' - 这似乎取决于OS /语言。例如，在Windows / C ++上，由于CPU密集型任务数量较多，因此最佳性能似乎远远超过核心数量的两倍，且性能分布非常小。如果这样的环境，你似乎也可以只在池上分配64个线程，而不必担心核心数量。
'query / query-ack和响应/响应 - 确认模型，时间不得浪费在I / O等待状态' - 对于大多数网络具有高延迟的此类协议，这是不可避免的。延迟是通过'乒乓'协议强制执行的。因此，不可避免地会有I / O等待。异步I / O只是将这个等待进入内核 - 它仍然存在！
'对动态内存有很大的要求，最好是采用比线程更多的进程 - 不是真的。 “对动态内存的大量需求”通常意味着大数据缓冲区将会被移动。大型缓冲区只能通过引用有效地移动。由于共享内存空间，这在线程之间非常简单快捷。使用流程，您会遇到尴尬和缓慢的进程间通信。
'确定我们应用程序中的线程数' - 好吧，在几个方面都很难。鉴于未知的架构，设计。语言和操作系统，我唯一的建议是尽可能灵活地配置所有内容。如果您有一个线程池，请将其大小设置为运行时参数，您可以调整它。如果您有一个对象池，请尝试设计它以便您可以更改其深度。有一些默认值适用于您的测试盒，然后，在安装或运行时，您可以对特定系统进行任何特定的更改和调整。
灵活/可配置设计的另一个方面是，您可以在测试时调整并修复由架构师，设计人员，开发人员以及最重要的客户做出的许多错误决策，假设和猜测