当前位置: 技术问答>linux和unix
服务器接受的链接过多,该怎么处理
来源: 互联网 发布时间:2016-12-18
本文导语: 每当客户端有一个请求链接时,服务器就accept,然后建立一个线程;但是服务器新建的线程有上限,例如1000; 当同时有1500个请求链接时,服务器只能处理1000个请求,产生1000个线程,这1000个线程都处于忙碌状态;那么剩下的500...
每当客户端有一个请求链接时,服务器就accept,然后建立一个线程;但是服务器新建的线程有上限,例如1000;
当同时有1500个请求链接时,服务器只能处理1000个请求,产生1000个线程,这1000个线程都处于忙碌状态;那么剩下的500的服务器改怎么处理?
方法:建立一个列队来存储这500个请求可以吗?我担心在等待服务器出现空闲线程时,等待时间过长,链接断开了
各位有什么好的方法来处理这个情况吗
|
我想这个问题和技术无关了,个人想法问题。
我的意思也不是不理睬这500个链接,而是返回一个服务器资源不足的信息给客户端就够了。
至于客户端,它有很多选择,比如选择其他服务器,或者过一会(比如你可以选择指数退避算法)再去请求也可以。
如果服务器能主动建立链接也可以,先把那500个请求的部分信息放入队列
服务器有资源了,再选择部分链接出来主动建立链接(如果没有特别要求就用先进先出算法)。
如果服务器不能主动建立链接也可以建立队列,有资源后去通知客户端重新发送请求。
|
其实也不一定的,凡是要分情况,看是什么类型的服务器。
比如IP媒体服务器(有创建视频会议的功能),假如它只支持3个视频会议同时进行,
某天下午的两天刚好同时有3个视频会议正在召开,最早的也要3点才能结束,3点后
服务器还要处理几个预约的视频会议,最早要4点才能处理完所有的会议。
在这种情况下如果2点30分的时候,有个用户要求建立连接,创建一个视频会议,
你是把这个请求放入队列然后一直等上2个小时,还是告诉客户现在没空,最早也要4点才有空。
如果我去处理,我会选择恢复客户现在没空,最早4点有空,问他是尝试其它服务器还是预约会议。
|
一个连接对应一个线程的设计本身就是有瓶颈的,建议使用iocp或者epoll来实现。
这样使用几个线程就可以处理上千个连接的io操作。
同时还应该使用消息队列,把真正的逻辑操作放到逻辑线程中。
网上有很多例子的,可以找一下,并不复杂。
这样使用几个线程就可以处理上千个连接的io操作。
同时还应该使用消息队列,把真正的逻辑操作放到逻辑线程中。
网上有很多例子的,可以找一下,并不复杂。
|
select模型不行吗?通常建立一个线程Accept接收客户端连接,将连接扔进接收数据线程,状态机进行数据处理,扔给发送线程回应客户端。其他的根据你的需要确定是否需要多线程处理,good luck。如果性能确实上不去再在处理线程那里采用多线程。socket的TCP关键是Accept,Send,Recv是阻塞的。此外TCP编程还应处理实际接收和发送的数据。
|
linux就可以先用 epoll模型.
Window 就可以选择 IOCP模型.两者各有优缺点.
不过呢,1500个连接用1500个线程处理,显然是不妥的.我想CPU花在切换上的时间都不知道花了多少了.
楼主去baidu一下,这两个模型吧.
Window 就可以选择 IOCP模型.两者各有优缺点.
不过呢,1500个连接用1500个线程处理,显然是不妥的.我想CPU花在切换上的时间都不知道花了多少了.
楼主去baidu一下,这两个模型吧.
|
可以用listen 建立一个队列,队列大小最小>1500,有连接请求是就会建立连接,在系统内核当中他会把所需要连接的请求分为2部分,一部分为已连接队列,另一部分就是未连接队列,当已连接队列为空时就会阻塞,在未连接队列中的队头就会建立TCP 3次握手连接,加入到已连接队列中。随后进行处理,所以没必要担心现成会在空闲的时等待时间过长断开连接。希望这些对你有帮助
|
瓶颈在于线程个数有限制..
用epoll检测监听套接字与已连接套接字,将新的连接套接字加入到集合里,将已连接套接字的数据到来作为一个task加入到全局队列里,唤醒一个线程去处理.
传统的都是一个客户对应一个线程,始终占有直到客户端断开连接.
现在是一个请求对应一个线程,处理结束便放掉了线程,所以一个线程已经不是在对应一个客户了,而是对应千千万万客户的千千万万个请求.
你应该知道线程里死循环,阻塞在条件变量上的,只有主线程给予通知才能唤醒,一旦唤醒,那么由于死循环检测缘故,如果我们只有1000个线程,而来了8000个请求,主线程不管3721,将8000个请求都加入队列,并且唤醒8000次,而实际唤醒1000次就唤醒了所有线程,而每个线程都是轮训检测的,所以将最终取完并处理所有在全局队列里的请求.
这就是一个线程对应多个客户,线程的工作周期不是和客户生命周期一样,而是随每一次请求而运作的.
用epoll检测监听套接字与已连接套接字,将新的连接套接字加入到集合里,将已连接套接字的数据到来作为一个task加入到全局队列里,唤醒一个线程去处理.
传统的都是一个客户对应一个线程,始终占有直到客户端断开连接.
现在是一个请求对应一个线程,处理结束便放掉了线程,所以一个线程已经不是在对应一个客户了,而是对应千千万万客户的千千万万个请求.
你应该知道线程里死循环,阻塞在条件变量上的,只有主线程给予通知才能唤醒,一旦唤醒,那么由于死循环检测缘故,如果我们只有1000个线程,而来了8000个请求,主线程不管3721,将8000个请求都加入队列,并且唤醒8000次,而实际唤醒1000次就唤醒了所有线程,而每个线程都是轮训检测的,所以将最终取完并处理所有在全局队列里的请求.
这就是一个线程对应多个客户,线程的工作周期不是和客户生命周期一样,而是随每一次请求而运作的.
|
epoll & IOCP
|
我也觉得对,使用epoll来做的话,那就是对着的是千千万万个请求的问题,而不是接受连接的问题了。
1:master+worker 处理,主进程负责创建监听 sockfd, 子进程负责epoll处理各个事件发生,检测到各个事件是读写事件或accept 进入不同队列。
2:各个进程对于处理accept事件接入时,使用锁来防止发生群惊,这样也会使得各个进程负载均匀。
3:各个子进程里面维护的是各自其accept上来的 sockfd, 那么这就会,即使其中一个子进程退出了,也不至于全部client退出,并且主进程可以通过信号来检测得到哪个子进程非正常退出了,然后重新建立进程。
看你业务需要,不是文件大信息类型的服务器,应该不用一条线程一个用户也处理的过来吧?
1:master+worker 处理,主进程负责创建监听 sockfd, 子进程负责epoll处理各个事件发生,检测到各个事件是读写事件或accept 进入不同队列。
2:各个进程对于处理accept事件接入时,使用锁来防止发生群惊,这样也会使得各个进程负载均匀。
3:各个子进程里面维护的是各自其accept上来的 sockfd, 那么这就会,即使其中一个子进程退出了,也不至于全部client退出,并且主进程可以通过信号来检测得到哪个子进程非正常退出了,然后重新建立进程。
看你业务需要,不是文件大信息类型的服务器,应该不用一条线程一个用户也处理的过来吧?