c - 什么是最好的，单线程或多线程服务器？

Question

我必须创建一个简单的客户端<->服务器通信以使用 C 语言 (Linux) 传输文件。

服务器在 10000 端口上接受连接，我不知道是每个请求创建一个新线程还是创建固定数量的线程并使用异步技术更好。

CASE A:

client --> server --> (new thread) --> process the request

CASE B:

SERVER --> create thread 1 - thread 2 - thread 3

then

client1 --> server --> thread 1
client2 --> server --> thread 2
client3 --> server --> thread 3
client4 --> server --> thread 1
client5 --> server --> thread 2
client6 --> server --> thread 3

在这种情况下，线程 1 可以处理许多客户端的请求

我的考虑:

案例 1:速度更快但浪费大量内存

案例 2:速度较慢但使用低内存

我错了吗？

Answer 1

如果你考虑检查广泛使用的 http 服务器(nginx、lighttpd、apache)的架构，你会注意到，那些使用固定线程数(所谓的“工作线程”，它们的数量应该取决于服务器上的进程或数量)的是很多 比使用大型线程池的速度快。然而，有一些非常重要的时刻:

1. “工作线程”的实现不应该像它看起来那么简单，否则不会有真正的性能提升。每个线程应该使用状态机实现每个伪并发，同时处理多个请求。此处不允许任何阻塞操作 - 例如，线程中等待硬盘驱动器 I/O 以获取文件内容的时间可用于解析下一个客户端的请求。不过，这是很难编写的代码。

2. 在考虑性能、编码时间和代码支持时，基于线程的解决方案(具有可重复使用的线程池，因为线程创建是重量级操作)是最佳选择。如果您的服务器不应该每秒处理数千个请求，您将能够以非常自然的阻塞方式进行编码，而不会冒性能完全失败的风险。

3. 如您所见，“工作线程”解决方案本身仅服务于静态数据，它们将动态脚本执行代理给其他一些程序。据我所知(可能是错误的)，这是由于在其上下文中执行一些未知动态内容的请求的非阻塞处理的复杂性。无论如何，这在您的情况下应该不是问题，因为您谈论的是简单的文件传输。

有限线程解决方案在重负载系统上速度更快的原因 - 线程 http://en.wikipedia.org/wiki/Context_switch这是一个非常昂贵的操作，因为它需要从寄存器中保存数据并加载新的数据，只要其他一些线程本地数据。如果与进程数相比线程太多(比如多 1000 倍)，应用程序中的大量时间将浪费在线程之间的简单切换上。

因此，对您的问题的简短回答是:“不，它与内存使用无关，选择完全取决于所服务的数据类型、计划的请求/秒数以及在编码上花费大量时间的能力”。