目的： 我试图估计我的代码在多个线程中并发运行时的执行速度。
问题1）
如果我确切地知道我的代码在一个线程中为单个请求运行的速度有多快，那么它们可以估计它在多个线程中运行的速度有多快？
问题2）
其他线程的存在会影响其他线程的执行速度，会产生什么影响？
我的情况：
我遍历最坏情况下100万个节点的内存图。它只是一次访问1个内存地址1。在1个线程上占用半秒钟，我担心这会在多个用户执行相同查询的情况下进行扩展。每个用户请求都由一个单独的线程处理，因此100个并发用户将需要100个并发线程。每个线程共享相同的资源但只读。没有写作。我有没有机会让每个用户看到大致相同的执行时间？
注意：我知道这将取决于许多因素，但肯定必须有一些方法来确定您的代码是否会扩展如果您发现 x 给出 x 硬件的单个线程的时间量。作为最后的注释，我想补充一点，我对计算机硬件架构的经验有限，以及多线程如何在幕后工作。
答案 0 :(得分：4)
这些都是有趣的问题，但不幸的是，没有直截了当的答案，因为答案取决于很多不同的因素。
大多数现代机器都是多核的：在理想情况下，四线程进程能够在四核机器中几乎线性扩展（即运行速度快四倍）
但是，大多数程序大部分时间都在等待：磁盘或数据库访问，内存总线，网络I / O，用户输入和其他资源。更快的机器通常不会使这些事情明显加快。
大多数现代操作系统（包括Windows，Unix / Linux和MacOS）使用处理器的方式是以一种或多或少的循环方式将处理器时间安排到进程和线程：在任何给定时间可能是等待处理器时间的线程（这有点过于简单，因为它们都有一些进程优先级的概念，因此高关键性进程比不太重要的进程更早地被推到队列中。）
当线程使用处理器核心时，只要其时间片持续，它就会 all ：实际上，一次只有一件事实际上在一个核心上运行。当进程耗尽其时间片，或请求某些不可立即获得的资源时，它在处理器核心处轮到它，并且下一个计划任务将开始。这倾向于使处理器资源得到最佳利用。
那么决定流程扩展程度的因素是什么？
单个进程花费等待的运行时间的哪一部分 I / O和用户输入？
多个线程是否会点击相同的资源或不同的资源？
线程之间需要进行多少通信？各个线程和你的进程主线程之间？这需要同步，并引入等待。
活动线程的热点有多“紧”？它的主体可以放入处理器的内存中，还是必须访问（慢得多）总线内存？
作为一般规则，独立的单个线程彼此越多，您的应用程序将越线性地扩展。但是，在现实世界的商业应用程序中，情况远非如此。提高流程扩展能力的最佳方法是理解它 - 及其依赖性 - 然后使用分析器找出最等待的位置，并查看是否可以设计技术策略来消除它们。
答案 1 :(得分：2)
如果我确切地知道我的代码在一个线程中为单个请求运行的速度有多快，那么它们可以估计它在多个线程中运行的速度有多快？
不，你应该凭经验确定。
其他线程的存在会影响其他线程的执行速度，会产生什么影响？
计算绑定任务可能会很好地扩展，并且大部分独立于其他线程。有趣的是，some CPU manufacturers implement features which can increase the clock of a lone-busy CPU core to compensate for the all the idle cores。这种功能可能会使您的测量和对缩放的期望感到困惑。
缓存/内存/磁盘绑定任务将开始相互竞争，除了资源分区存在的位置。
我知道这将取决于许多因素
绝对！因此，我建议您对其进行原型设计并进行测量。然后找出为什么它没有像你希望的那样扩展，并尝试不同的算法。迭代。
但肯定必须有某种方法来确定您的代码是否会缩放
是的，但不幸的是，它需要详细描述代码实现的算法。您的结果将在很大程度上取决于您的代码在这些常规区域中的活动比例，以及您的目标对这些区域的能力：
我的情况：我的应用程序在app服务器中运行，为每个用户请求分配一个线程。如果我的应用程序在2秒内为1个用户执行，我不能假设如果说100个用户同时运行相同的操作正确，则总是花费2秒钟？
如果您的应用服务器为每个用户请求计算pi到100位数，那么在您遇到目标的核心限制之前，它可能会合理地扩展。
如果您的应用服务器针对每个用户请求执行数据库查询，则它可能只会扩展，因为目标硬件可以承受必要的负载。
EDIT给出具体细节：
我遍历最坏情况下100万个节点的内存图。它一次只能访问1百万个内存地址。
你的问题听起来像内存+缓存限制。您应该研究目标CPU /内存部署的详细信息，或者如果您正在设计它，请选择高内存吞吐量。
有限的计算机硬件架构经验以及多线程如何在幕后工作。
使用英特尔VTune，perf或oprofile等工具，使用CPU性能计数器对查询进行配置。它可以告诉您代码中执行昂贵操作的位置。有了这些信息，您可以优化您的查询以表现良好（单独和聚合）。