freemarker性能问题

今天对blogDetail性能测试，相比django, ibatis+mongodb/mysql+spring mvc给力太多。之前在django上面需要200多ms在，tomcat只需要40ms，后端control通过btrace打点耗时20ms, 模板20ms，freemarker的性能确实不怎样。(这里忽略了spring-mvc的执行时间，应该耗时不多)

freemarker和velocity的核心实现都是一样的，都是先用JavaCC把文法文件转换成Parser和TokenManager，
然后Parser和TokenManager在运行时把模板解析为一棵抽象语法树(AST)，最后再从上往下遍历这棵树，树结点有很多类型(比如Reference、Method、MathNode等等)，对这些树结点"求值"，最后把结果放入一个Writer中。

从淘宝那边了解到，他们也在对Veclocity的执行效率优化。如果只是将Velocity编译成弱类型字节码，性能提升不会太大，JavaCC生成的AST就算是解释执行效率也是很高的，反而对String和byte的多次encode/decode转化处理下，提升的非常明显。因为一个页面90%都是静态的html,大概原理是将这html预先生成byte并cache住，再对动态变量生成string字符串，只对这10%的decode后转成byte,最后输出时将两段byte拼接一下即可，从测试的数据看，将大模板折成小模板（提升35%），将String缓存后，用byte[]输出，性能提升幅度很大（提升50%），而编译成字节码反而收效少（提升10%）。

附件中淘宝做了一个测试char to byte的对比，性能提升明显

//测试例子1:
private static String content = “...94k...”;
protected doGet(...){
response.getWrite().print(content);
}


//测试例子2:
private static String content = “...94k...”;
Private static byte[] bytes = content.getBytes();
protected doGet(...){
response.getOutputStream().write(bytes);
}

qps:1800
qps:3500

可以参考附件的淘宝前台系统优化实践

猜你喜欢