收藏一个代码脚手架:spring mvc + 嵌入式jetty + maven
http://steveliles.github.io/setting_up_embedded_jetty_8_and_spring_mvc_with_maven.html 有一点:webapp应放在 "src/main/ resources/META-INF/webapp" 下, 而不是"src/main/ java/META-INF/webapp"下,否则,用maven打包时会丢失这些非java文件
http://steveliles.github.io/setting_up_embedded_jetty_8_and_spring_mvc_with_maven.html 有一点:webapp应放在 "src/main/ resources/META-INF/webapp" 下, 而不是"src/main/ java/META-INF/webapp"下,否则,用maven打包时会丢失这些非java文件
http://blog.lifeibo.com/blog/2011/07/07/200-long-connection.html http://blog.yufeng.info/archives/1380
1. 请求的数据量大小(字节数) 2. 每秒请求数 a. 短连接应用:不必多说 b. 长连接应用:大量连接建立请求 3. 在线数 a. 短连接应用:Session数 b. 长连接应用:维持的长连接数(socket数) 4. 留存数据量: 数据库里已有的数据量 待续。。。
尽量将性能环境的以下参数调成跟生产环境一致: 1. 硬件 2. 网络 3. log日志级别 待续。。。
消息中间件可能重发消息,怎么办?只能要求客户端保证幂等性了。 但这又增加了客户端的复杂性,人家可能不愿意。 其实解决办法很简单(也很流氓),你自己做个客户端SDK,在这里面做好消息去重,然后让你的客户集成它就是了。
有必要搞pipeline之类的东西吗? 把各块功能封装成独立的API,然后每个request handler分别调用不同的api组合不就行了吗?这样还免得搞框架,也不用写什么配置文件。 这种质疑不是没有道理,但最近的亲身体会表明,pipeline体系在开发效率、代码正确率上有确有一定优势。 比方说,要加一个切面功能的话,Pipeline模式中开发者要在各个request handler的xml配置中加上一行,API模式中开发者要修改各个 request handler类。 比较: 1. 在xml中加配置肯定比在各个类中加代码更快 2. 在xml中加不易出错,而在各个类代码中改相对容易出错 a. java代码在结构上不如xml文件清晰,插错地方的可能性比较高 b. 在java代码中新增API调用语句前要先收集输入,如果插入点的上下文没有直接可用的变量作为输入,则需要重构代码,引发bug隐患; 在xml中配置没有这个问题,因为pipeline体系中强制规定了输入变量应从pipeline context中获取,总是能获取到的。 c. 在java代码中调用API后要根据输出和异常决定下一步怎么走,这可能导致比较大的流程变更,而且不同的request handler需要做不同的变更,这非常容易出错; 在xml中配置没有这个问题,因为pipeline体系各valve自己已经决定了下一个出口,不需要调用者操心。 总结一下,pipeline体系中的处理结点是特殊的API,它们有高度统一的接口和更高的自恰性,组装起来比普通API更容易,所以应对功能变更的能力也更强。