- 论坛徽章:
- 4
|
本帖最后由 linux_c_py_php 于 2012-11-10 11:53 编辑
看样是TIME_WAIT引起的, 端口被占用光了, 优化一下网络配置吧, /etc/sysctl.conf, 相关文档给你贴俩连接, 这些在<linux性能优化>那本书里是有提及的, http://www.cnblogs.com/hbycool/articles/2269326.html.
至于怎么做一个高效的proxy, 大致可以想到不同层次的几种实现手法, 并且楼主看样还不需要向client返回backend的应答:
1, 线程池, 每个线程单连接阻塞处理, 连接由监听线程accept后派发到空闲线程(适合queue+mutex+cond方式)
2, I/O复用(异步), proxy->backend采取短链接, 每一次请求出发Dproxy向backend发起短连接, 对client保持短连接或者长连接都随意.(甚至结合1,2, 线程池, 每个线程维护一堆连接, 只不过是提高并发能力而已.)
3, I/O复用, proxy->backend采取简单的长连接, 即在client第一次请求时dproxy->backend发起长连接,并与client保持长连接, client多次连续请求均可通过一条->backend的长连接持续处理.
4, I/O复用, 但backend要求预先配置好不可变, 因为前面3种是完全可以让client携带backend地址的. backend预配置的情况下, 就可以做不同的架构了, 那就是把proxy逻辑挪到client I/O 线程之外作为独立线程, proxy线程依然I/O复用异步, 但内部是维护好长连接池的, I/O主线程与proxy I/O线程间采用pipe+queue的方式异步通信, proxy要做的只是把请求丢到对应的连接的写队列里, 如果backend长连接失效, 还需要非阻塞的把连接重新建立起来, 并丢弃掉未完整写出的请求.
5, 最顶级的做法, 单线程完全异步proxy逻辑, 与方法3相同, 即到proxy的连接是第一次请求触发的长连接, 但架构上我们有能力让proxy解耦开来作为一个plugin工作, 具体参考https://github.com/liangdong/Server. |
|