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

发布时间：2020-12-13 19:00:32 所属栏目：Linux 来源：网络整理

导读：我必须创建一个简单的客户端服务器通信来使用C语言(Linux)传输文件. 服务器接受10000端口上的连接,我不知道是否更好地为每个请求创建一个新线程或创建固定数量的线程并使用异步技术. CASE A:client -- server -- (new thread) -- process the requestCASE B

我必须创建一个简单的客户端< - >服务器通信来使用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：速度较慢但使用较低的内存

我错了吗？

最佳答案

如果你考虑检查广泛使用的http服务器(nginx,lighttpd,apache)的体系结构你会注意到,使用固定线程数的那些(所谓的“工作线程”,它们的数量应该取决于服务器上的进程数)要快得多然后一个使用大线程池.但是,有非常重要的时刻：

>“工作者线程”的实现不应该像诱人的那样简单,否则就不会有真正的性能提升.每个线程都应该使用状态机实现每个伪并发,并及时处理多个请求.这里不允许阻塞操作 – 例如,从硬盘驱动器等待I / O获取文件内容的线程中的时间可用于解析对下一个客户端的请求.不过,编写代码非常困难.
>在考虑性能与编码时间与代码支持时,基于线程的解决方案(具有可重用线程池,因为线程创建是重量级操作)是最佳的.如果您的服务器不应该每秒处理数千个请求,您将能够以非常自然的阻塞方式进行编码,而不会有完全失败的风险.
>正如您所注意到的,“工作线程”解决方案本身仅为静态数据提供服务,它们将动态脚本执行代理到其他程序.据我所知(可能是错的),这是由于非阻塞处理请求的复杂性以及在其上下文中执行的一些未知动态内容.无论如何,当你谈到简单的文件传输时,这不应该是你的问题.

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

因此,对您的问题的简短回答是：“不,它与内存使用无关,选择的是所提供的数据类型,计划的请求/秒计数以及在编码上花费大量时间的能力”.

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!