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

开发高性能的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必须要能够分数据块在用户扩展中进行处理。

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

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