光为压力测试的话，你的测试进程多跑个不就好了么，性能还更好:)

不明白楼上的意思。

简直是搞笑，无论把openfiles设多大总有用尽的一天。

老大你还没到25岁吧，管理层如果很看重你那也是利用你年轻有力气，不是看中你的才能，觉悟吧。

抱歉扯远了。

你的服务程序有大问题，怎么能用一个程序处理这么多请求。一楼的话都不懂。处理大规模并发要用多个服务进程的。

回复楼上：

如果一直大规模并发，描述符肯定会用尽的，用单进程是项目的要求，而且实际并发请求数也不会达到1w，所以服务器架构用的是单进程+线程池。

当然，超大规模的并发，就要改用集群了，而不仅仅是描述符耗尽的问题了。

呵呵，关于你的力气与才能的判断，我不想多说，其实我是一个很平凡的人，做好自己的实事求是的事，而不是套框架，这样足够了。

呵呵，其实这也就是我平时工作学习碰到的一些问题，贴出来，或许能够帮助别人一点。这个服务器架构不是我定的（部门里好几个资深的工程师一块商定的），因为考虑到和别的部分的协调以及能够使别的部分改动最少。还有，这个服务器和客户端是使用本地套接口通信的，也就是说，客户端和服务端在同一个机器上，每个客户端都是一个进程（客户端再通过网络与外界通信），这也是使用单进程服务器的一部分原因了。

本地通讯用socket通讯恐怕也有点勉强吧，不知道这么多资深的工程师怎么不用IPC。难道就是为了考验你能不能解决描述符的问题？

Blog作者的回复:
因为实际的并发量只有2000左右，而且在实际中根本就不存在描述符的问题，IPC当然可以，UNIX域套接字也是通过管道实现的，没什么不妥，你说的描述符问题在我的实际问题中不会出现。

楼上的第二个回复我删掉了，现在把你的问题贴出来，并附上我的回复：

阁下的问题：

顺便问一下这个服务程序还有别的特殊要求吗，比如内存必须不能超过1M代码不能超过几行什么的，呵呵。

内存有限制，但不会限制在1MB之内，代码量没有要求。



ps：如果你觉得服务器架构有问题，那是你的问题，因为在实际应用中，我的这个架构没有问题，工作的很好。