为什么JSP会比Beetl慢
许多人都不相信这个事实,作为前端常用渲染技术,JSP比Beetl慢。如果稍微了解这俩种技术的人,会分析:JSP是编译成class的,而 Beetl总是解释执行的。JSP肯定会比Beetl快。然而,事实并不是这样,通过了许多性能测试,证明,Beetl还是要快的,如下是TEB模板引擎 性能基准测试结果:
可以看出,代表Beetl的绿色的,性能高于代表JSP的黄色大约2倍。
还有个帖子来自osc:http://my.oschina.net/tangcoffee/blog/303865,压力测试jsp和beetl,证明beetl性能是JSP的2倍,如下是截取的部分数据
采用jfinal+beetl模板,apache ab压力测试结果
-
Time taken for tests: 0.656 seconds
-
Complete requests: 1000
-
Time per request: 32.813 [ms] (mean)
未采用beetl,apache ab测试结果:
-
Time taken for tests: 1.297 seconds
-
Complete requests: 1000
-
Time per request: 64.844 [ms] (mean)
究竟怎么回事情,使得编译执行的JSP执行比解释执行的Beetl慢。基本上来说,Beetl并没有做出超越常规的性能优化,而是JSP本身性能优化不够导致的。
第一: JSP对静态文本处理的不够好 。
如果你看看JSP编译的后的java代码(以Tocmat7为例),你会发现,JSP并没有优化好静态文本输出。如下一个JSP代码
- <%@ page language="java" contentType="text/html; charset=ISO-8859-1"
- pageEncoding="UTF-8"%>
- <html>
- <head>
- <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
- <title>Test JSP</title>
- </head>
- <body>
- <%
- String a = "Test JSP";
- %>
- <%=a %>
- </body>
- </html>
Tomcat7 会编译成为
- out.write("<html>\r\n");
- out.write("<head>\r\n");
- out.write("<meta http-equiv=\"Content-Type\"
- content=\"text/html; charset=ISO-8859-1\">\r\n");
- out.write("<title>Test JSP</title>\r\n");
- out.write("</head>\r\n");
- out.write("<body>\r\n");
- String a = "Test JSP";
- out.write('\r');
- out.write('\n');
- out.print(a );
- out.write("\r\n");
- out.write("</body>\r\n");
- out.write("</html>");
可以看出,对于静态文本,JSP会多次调用out.write方法,而write方法内部,每次调用,都会做flush检测等耗时机制。因此,更好的方式应该是将静态文本合并一次性输出,应该是下面这种会更好点
// 期望JSP的样子
- out.write("<html>\r\n<head>\r\n ....<body>\r\n“);
- String a = "Test JSP";
- out.write("\r\n“);
- out.print(a );
- out.write("\r\n</body>\r\n</html>");
第二 就算JSP的实现做了如上更改,静态文本处理还有优化空间。这是因为互联网传输的二进制,因此会存在一个将静态文本转成 byte[] 输出的过程,这是一个耗费CPU操作的过程,也就是JSP里的write操作,内部还大量的编码,而且,随着JSP一次次渲染,编码是一次一次重复,实验 证明,这极大的降低了JSP性能。通过如下伪代码可以验证 输出是: jsp total=228 beetl total=3 可见Beetl将静态文本预先编码成二进制,会提高性能很多。而通常JSP,总是静态文本多过JSP Code的 第三,JSP在JSTL做的不够完美,也导致性能很差。 由于JSP是基于Java语言,语言本身是OO的,很多地方不适合模板场景使用,因此,自然而然采用JSTL来弥补JSP的不足,这也是后来很多项目都基本上采用了JSTL来写模板。然而,JSTL的性能更加有问题。比如下一个简单的JSTL判断 在我最初的想象里,我认为jsp至少会编译成如下代码: //期望JSP能编译成如下代码 但事实并不是这样,对于如上JSTL,编译成 也就是,JSP并没有如预期的预编译成java代码,而是动态解释执行了 test条件,这样,性能不差才怪呢. 综上所述,JSP之所以在基准测试还是实际的测试,都比Beetl慢不少,是因为他静态文本输出方面没有去做积极的优化。像JSTL那样的的解释执行也极大的拖了JSP后退,而Beetl避免了这些问题。
相关文章
- JetBrains用Kotlin布了一个大局
- 年终盘点:Java今年的大事记都在这里!
- 如何在您的Java应用中查找并修复内存泄漏
- 为什么说Kotlin的可读性比Java好?
- 不想再被鄙视?那就看进来! 一文搞懂Python 2字符编码
- Java发展前景与职业方向解析
- 6个能让你的Kotlin代码库更有意思的“魔法糖”
- 探讨Java中最常见的十道面试题(超经典)
- 从源码解密Spark内存管理
- 最全的C++资源大全,纯干货!
- 调查显示新发布的Java9不太受欢迎
- 机器人研发热门语言:不死Java、不朽C/C ++、新贵Python
- 白话说Java线程(二)—让线程优雅的停下来
- 资深架构师解读Java多线程与并发模型之共享对象
- 资深架构师解读Java多线程与并发模型之锁
- Java中的注解是如何工作的
- 11个简单的Java性能调优技巧
- 做前端好还是Java好?看这三方面
- Java EE成为过去,Eclipse为其“改名”望成为顶级开源项目!
- 程序员花2小时总结:20个非常有用的Java程序片段