与多线程相比，多处理是否可以加快文件传输

Question

我正在编写一个脚本，以同时使用套接字从子网上的许多计算机上接受许多文件传输（总共约40个jpg文件）。我想使用多线程或多处理来使传输尽快发生。

我想知道这种类型的图像传输是否受CPU限制-因此我应该使用多处理-还是在这里多线程处理同样好。

我还想知道哪些类型的活动受CPU限制并需要多处理，而哪些活动更适合多线程。

Answer 1

如果满足以下假设：

1. 您的脚本只是简单地从网络接收数据并将数据逐字写入磁盘（或多或少），即它并未对数据进行任何昂贵的处理
2. 您的脚本正在具有典型现代网络硬件（例如千兆位以太网或更慢）的现代CPU上运行
3. 您的脚本的下载例程效率不是很高（例如，您正在接收大小适当的数据块，而一次接收的不仅仅是一个字节或类似的东西）

...则您的下载速率不太可能受CPU限制。瓶颈可能是网络带宽或磁盘I / O带宽。

无论如何，由于AFAICT的用例令人尴尬地是并行的（即各种下载永远不必相互通信或交互，它们只是各自独立地做自己的事情），因此使用多线程与多处理不会使在性能方面有很大差异。当然，唯一可以确定的方法是尝试两种方法，并分别测量每种方法的吞吐量。

Answer 2

简短答案： 通常，这实际上取决于您的工作量。如果您对性能很重视，请提供详细信息。例如，是否将图像存储到磁盘，图像大小是否大于1GB，等等。

注意：通常，如果不是关键任务，则两种方法都是可以接受的，因为我们可以使用threading.Thread和multiprocessing.Process轻松在多线程和多进程实现之间切换。

更多评论 似乎不是CPU，而是IO将成为瓶颈。

对于多进程/多线程，由于GIL和/或您的实现，我们可能会有性能差异。您可以同时实现并尝试。顺便说一句，恕我直言，它不会有太大区别。我认为异步IO与阻塞IO会有更大的影响。

Answer 3

如果文件传输不是非常慢-比将数据写入磁盘慢，那么多线程/多处理将无济于事。通过文件传输，我的意思是下载图像并将其通过单个HDD写入本地计算机。

从具有单独磁盘的多台计算机传输数据时，使用多线程或多处理程序无疑可以提高整体下载性能。可以并行读取从多个物理磁盘读取的数据。当您尝试将这些图像保存到本地驱动器时会出现问题。

您只有一个本地HDD（如果未使用磁盘阵列），则像大多数HW设备一样，单个HDD一次只能执行一次IO操作。因此，尝试同时将多个映像写入磁盘不会提高总体性能-甚至会妨碍它。

想象一下，正在尝试将40个已经下载的图像写入具有单个HDD磁头的单个机械HDD的不同位置（不同的物理文件），特别是如果磁盘碎片化的情况。然后这甚至会减慢整个过程，因为HDD浪费了将磁头从一个位置移动到另一个位置的时间（驱动器可以通过重新排序IO操作以限制磁头移动来部分缓解这种情况）。

另一方面，如果您对这些图像进行一些CPU密集型的预处理，然后才将其保存到磁盘，那么多线程真的很有帮助。

还有一个问题是什么是首选。在现代操作系统上，使用多线程和多处理（跨多个进程）之间没有显着差异。像Linux或Windows这样的操作系统会根据进程和线程的优先级来调度线程而不是进程。因此，40个单线程进程和一个包含40个线程的进程之间没有太大区别。使用多个进程通常会消耗更多的内存，因为每个进程的OS必须分配一些额外的内存（不大），但是从速度的角度来看，多线程和多处理之间的差异并不大。还有其他重要的问题需要考虑使用哪种方法（这些下载是否会共享一些数据，例如通用的GUI界面-多线程更易于使用），（这些文件下载得太大了，以至于40次传输会耗尽一个虚拟机的所有虚拟地址空间）单进程-使用多进程）。

通常：

多线程-易于在单个应用程序中使用，因为所有线程共享单个进程的虚拟地址空间，并且可以轻松地彼此通信。另一方面，单个进程的虚拟地址空间大小有限（在32位计算机上小于4GB）。

多重处理-难以在单个应用程序中使用（需要进程间通信），但是更具可伸缩性和更强大（如果文件传输过程崩溃，只有单个文件传输失败）+要使用的虚拟地址空间更多。 / p>