Java Servlet为什么不做成FastCGI模式?

什么PHP,Python,Perl的解释器都是以FastCGI模式加载到Web服务器的,这样性能较高。servlet却不是如此,而是web服务器遇到动…
关注者
110
被浏览
23,287

5 个回答

1. 谁说没有呢? sourceforge.net/project

2. 动静态页面的分离可以考虑用Apache HTTPD + Java Application Server配合实现。

从产生背景来讲,FastCGI是为了解决CGI的问题而产生的,而Java Servlet则是自成一套,当然由于Java的单进程多线程环境,生来就会比CGI要优秀。从目前市场上来看,Java Servlet/JSP 着重针对企业应用开发,直接拿JSP/Servlet开发网站相对比较少,但是总的来说,都还是以PHP/PYTHON/RUBY + Apache/Nginx/LightHTTPD为主。

Java的技术体系是自成一套的,它和其他的动态Web技术相比较,有自己的发展侧重点。窃以为,目前很多基于Servlet技术的web应用服务器并不会以处理大访问量和并发为主要设计诉求,足够用就行。

托管运行环境(JVM/CLR)的健壮性已经足够高了,不会存在native程序那种sudden death(access violation、segmentation fault),有的只是servlet抛出的异常。何况设计良好的Servlet Container也有重启机制,所以不必担心健壮性问题

另外一个是效率问题,进程内传递数据只是一个引用,同一份数据无需反复多次解析。而FastCGI之类通过IPC、环境变量传递数据,毫无疑问会面临数据序列化、拷贝、反序列化的overhead,而且这还是单程通讯的开销

关于动静态页面分离,这是一个架构的复杂度和效率的取舍。首先你不要想当然认为不分离性能就不好。设计良好的servlet application自然有caching机制,用java写的hashmap在很多情况下benchmark还比native的版本高

Servlet方案的瓶颈在于线程的动态管理、调度成本高过Async I/O,但那往往是访问请求到10K/S以后的事。而且到了那个层面,优先考虑的不是单机的Scale up问题,而是整个机群的Scale out问题