为了在Linux上开发一个高度networking密集的服务器应用程序，什么样的架构是首选？ 这个想法是，这个应用程序通常运行在具有多个内核（虚拟或物理）的机器上。 考虑到性能是关键标准，最好去multithreading应用程序还是使用多进程devise的应用程序？ 我知道，资源共享和同步从多个进程访问这些资源是很多编程开销，但如前所述，总体性能是关键要求，所以我们可以忽略这些东西。 编程语言是C / C ++。
我听说即使是multithreading应用程序（单进程）也可以利用多个内核，并且独立地在不同的内核上运行每个线程（只要没有同步问题）。 这个调度是由内核完成的。 如果是这样，multithreading应用程序和多进程应用程序在性能上没有太大的区别？ Nginx使用多进程架构，并且非常快，但是multithreading应用程序可以获得相同的性能吗？
谢谢。
linux上的进程和线程彼此非常相似 – 主要的区别是整个虚拟内存是共享的，以及像信号处理这样的某些东西是不同的。
这使得线程之间更便宜的上下文切换（不需要昂贵的MMU重新加载等），但不一定会造成速度上的差别（特别是线程创建之外）。
为了设计一个高度网络密集的应用程序，基本上唯一的解决方案是使用一个平衡的架构（否则你会使系统拥有大量的进程/线程，花费更多的时间在他们的管理上，而不是实际运行的代码）对套接字上的I / O做出反应，并根据哪个套接字显示活动执行适当的操作。
关于在这种情况下面临的问题的一个着名的写法是“C10k问题” ，可从http://www.kegel.com/c10k.html获得 – 它描述了不同的I / O方法，所以尽管有点过时了，但它是很好的介绍。
尽管如此，在深入研究类反应堆设计之前要小心，它们可能会变得笨重和复杂，所以看看你是否不能使用提供更好的抽象的库/语言（Erlang是我个人最喜欢的语言，具有协程像Go也可以是有用的）。
如果你的线程独立完成这个工作，那么在linux下，没有理由不去使用多个进程。 多个进程会增加你的内存使用量，因为每个进程都有自己的私有内存空间，但另一方面，在独立线程之间共享内存空间是更糟糕的决定。 线程与进程之间的上下文切换通常对于进程而不是线程来说更好，尽管它的体系结构和代码依赖一点点。 进程是安全的，不会被锁和互斥体序列化。 在Linux中，进程更容易管理和交互。 这里是一个很好的文档，您可能会感兴趣（ http://elinux.org/images/1/1c/Ben-Yossef-GoodBadUgly.pdf ）。