性能 - 多线程或多进程应用程序 [英] performance - multithreaded or multiprocess applications

问题描述

为了在 linux 上开发高度网络密集型的服务器应用程序，首选哪种架构?这个想法是这个应用程序通常会在具有多核(虚拟或物理)的机器上运行.考虑到性能是关键标准，选择多线程应用程序还是多进程设计的应用程序更好?我确实知道从多个进程共享资源和同步访问这些资源是很多编程开销，但如前所述，整体性能是关键要求，因此我们可以忽略这些事情.并且编程语言是 C/C++.

In order to develop a highly network intensive server application on linux, what sort of architecture is preferred? The idea is that this app would typically run on machines with multiple cores (either virtual or physical). Considering that performance is the key criteria, is it better to go for a multi-threaded application or the one with multi-process design? I do know that sharing of resources and synchronization to access of such resources from multiple processes is a lot of programming overhead, but as mentioned earlier overall performance is the key requirement and so we can ignore those things. And the programming language would be C/C++.

我听说即使是多线程应用程序(单个进程)也可以利用多个内核并在不同内核上独立运行每个线程(只要不存在同步问题).而这个调度是由内核完成的.如果是这样，多线程应用程序和多进程应用程序在性能上没有太大区别吗?Nginx 采用多进程架构，速度确实很快，但是多线程应用能获得同样的性能吗?

I have heard that even the multi-threaded applications (single process) can take advantage of multiple cores and run each thread on a different core independently (as long as there is no sync issues). And this scheduling is done by the kernel. If so, is there not much difference in performance between multi-threaded applications and multi-process applications? Nginx uses a multi-process architecture and is really quick, but can one get the same performance with multi-threaded applications?

谢谢.

推荐答案

Linux 上的进程和线程非常相似——主要区别在于整个虚拟内存是共享的，而信号处理等某些方面也不同.

Processes and threads on linux are very similar to each other - the main difference is that the whole virtual memory is shared as well as certain things like signal handling differ.

这使得线程之间的上下文切换成本更低(不需要昂贵的 MMU 重新加载等)，但不一定会导致速度差异很大(尤其是在线程创建之外).

This makes for cheaper context switches between threads (no need for costly MMU reloads etc.) but doesn't necessarily cause much difference in speed (especially outside of thread creation).

对于设计一个高度网络密集型的应用程序，基本上唯一的解决方案是使用事件架构(否则你会因为大量进程/线程而使系统陷入困境并花费更多时间在他们的管理而不是实际运行工作代码)，您可以在其中对套接字上的 I/O 做出反应，并根据哪些套接字表现出活动来执行适当的操作.

For designing a highly network intensive application, basically the only solution is to use an evented architecture (otherwise you'll bog down the system with huge amount of processes/threads and spend more time on their management than actually running work code), where you react to I/O on sockets and based on which sockets exhibit activity do apropriate operations.

关于这种情况下面临的问题的著名文章是C10k 问题"，可从 http://www.kegel.com/c10k.html - 它描述了不同的 I/O 方法，所以尽管有点过时，但它是一个很好的介绍.

A famous writeup about the problems faced in such situations is "The C10k problem", available from http://www.kegel.com/c10k.html - it describes different I/O approaches, so despite being a bit dated, it's a very good introduction.

不过，在深入研究类似反应器的设计之前要小心——它们可能会变得笨拙和复杂，所以看看你是否不能使用提供更好抽象的库/语言(Erlang 是我个人最喜欢的，像 Go 这样的带有协程的语言也很有用).

Be careful before jumping deeply into reactor-like designs, though - they can get unwieldy and complex, so see if you can't use library/language that provides a nicer abstraction over it (Erlang is my personal favourite in this, languages with coroutines like Go can be useful too).

这篇关于性能 - 多线程或多进程应用程序的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！