开发高性能的j2ee应用服务器，或许只有舍弃掉现有servlet架构

近期在开发一个基于java的应用服务器。目标是在一台机器上能够支持尽量多的并发连接和可针对负载自动调整运行期资源占用量的多应用支持。

开始的想法很简单，参考jetty,tomcat和resin，能用他们的就用他们的。于是选定了jetty6（由于其结构清晰，可扩展性强）作为基础在其之上进行扩展。先作的是“可针对负载自动调整运行期资源占用量的多应用支持”部分，很顺利，新写了个jetty的contexthandler，然后建立一个线程来监视所有context的负载情况并管理加载、卸载就可以了。

可是在作压力测试的时候问题出来了，即便是空负载，系统的性能相对连接的并发数呈现指数级降低。1000并发条连接下，每秒处理请求数仅仅只有30个不到。而在1个连接下，每秒处理请求数能达到1000个。本以为是jetty的网络部分有问题，可是测试了tomcat,resin后，发现他们在同样连接条件下的性能都差不多。为了比较，我又测试了一下iis的性能，可是结果让我很吃惊，1000连接下iis每秒能处理的请求数是1200个......

看来问题相当严重，我不得不静下心来研究问题出现的根源。

一切的矛头都指向了j2ee请求处理的架构~~~~~~~

众所周知，j2ee应用服务器必须实现javax.servlet包下面的接口，简略来说，主要就是Request,Response和Servlet接口。所有的请求都会通过Servlet.service(request,response)进行处理。

换句话说，就是应用服务器必须准备好了request和response才能调用servlet去处理。这是啥子意思？这就是个典型的多线程处理架构。每个连接一个线程，每个线程去处理自己拿到的请求。

可是当高并发的时候，还能给每个request开个线程去处理么？大量的线程足够拖垮你的服务器。

而现在网络高并发开发已经不再是一个线程对应一个连接的时代了。现在高效的是异步并按块处理数据。windows下使用完成端口，linux下使用epoll,都是接到一个数据块就直接处理一个数据块，最多开少数几个工作线程去处理数据就足够了。这才是高效的处理方式。

javax.servlet在结构上根本就不支持异步处理的方式，也不支持按块处理。而多数java应用服务器为了支持javax.servlet，也不得不使用多线程的处理架构。

最近的趋势是使用nio做网络处理，nio理论上的确能提高并发处理性能，但是为了javax.servlet,后面还是挂了个线程池去每个请求分配一个线程。所以性能还是无法有质的提高。

痛定思痛，javax.servlet的结构已经不适合作高性能的应用服务器了。既然不适合，那我可能就只有抛弃掉它。虽然前面的道路可能会很艰苦.......

作为替代方案，我计划采用异步型接口重写应用服务器架构，网络部分先用isapi直接使用iis（linux下计划用lighttpd的mod）.request,response必须要能够分数据块在用户扩展中进行处理。

现在还没有完整的方案，很多事情要边做边测试才能知道。希望工作量没有大到无法承受。

希望听到朋友们的建议，或者不需要那么大动干戈....欢迎指教

目前放弃Servlet，不敢去想。。。。。。。。。。。

servlet不过是一些接口和抽象类，你完全没领会到含义

使用apr在测试一下

apr没有测试过，不过倒是测试过apache2.2,这东西在windows下性能差的一塌糊涂，仅仅比tomcat强了一点点。或许是没有使用完成端口的mdm造成的。linux下的表现也不是很让人满意，不如lighttpd....

如果有朋友有相应的测试数据，也请共享一下，主要和iis进行对比就可以了。

的确是这样
换句话说，就是应用服务器必须准备好了request和response才能调用servlet去处理。这是啥子意思？这就是个典型的多线程处理架构。每个连接一个线程，每个线程去处理自己拿到的请求。

一个建议，
采用Bea JRocket JVM再测试一下，看性能差距有多少

用叻Jetty的SelectChannelConnector吗？

“近期在开发一个基于java的应用服务器。目标是在一台机器上能够支持尽量多的并发连接和可针对负载自动调整运行期资源占用量的多应用支持。”
就是含糊的，可以采用各种方式来提高系统的并发能力，比如：使用集群方案，进行大量任务的转发，后端有同构服务进行支持。前端可以采用:apache,lighttpd,nginx,haproxy等等。
从Connector方式出发可以进一步提高tomcat的连接处理能力，apr,NIO都不错的，关于JDK性能BEA的和SUN的差不多!

需求是在单台机器上构建，不能考虑集群方案。不过这次也会注意集群方案的支持性。

前面我有些偏激了，虽然servlet不是最高性能的架构，但是它却非常容易进行扩展，也非常适合同步组件占据大多的java编程。看来还是必须支持的。不过要在其前端做好静态文件的处理工作，用servlet去处理静态文件的传输，效率实在是太低。另外，servlet对大量数据的post执行效率也不会太好，应该可以在处理过程上进行优化。

看起来第一步还是先对connector下手，改善connector的并发处理能力。后端用请求队列+连接池处理servlet.

然后就是必须限制servlet的执行时间，尽量减少等待（这一部分可能会很难控制，因为servlet会由用户来写。）争取设计为让用户写可控脚本而取代写servlet.

谢谢各位的建议...