J2EE系统优化讲稿.pptVIP

主讲：罗翔 罗翔 (Ation Row)个人介绍 重庆邮电大学计算机应用硕士,系统架构师 J2EE 领域专家，精通多种开源J2EE体系架构 IBM WebSphere产品资深专家（WAS,WBI,MQ) RIA 领域专家（精通RIA的两大方向AJAX与Flex) SOA 体系架构专家，ESB 资深研究与实践者 通信行业和互联网多个巨型项目的系统架构设计领导者，15年系统设计与开发经验。 为什么需要性能优化？ * * 使用数据库 用正确的方式创建连接 1）在创建数据库的连接时，使用连接池 2）不要在业务流程中传递数据库连接来保证事务，而应该使用其他的方式 3）在连接使用完毕后，显式地使用close方法来关闭连接 4）在一个完善的体系架构中，以上三点都在系统的基本架构代码上得到了完整可靠的保证，因此，需要强调的是，不要试图在这一点上去突破你团队的体系架构。比如通过代码来创建连接等等，这样将会造成不可预知的性能问题。 使用数据库 在高层业务代码中我们要做的 public List getWFRouteByNode(String nodeNo, String version) { List list = null; WorkFlowRowMapper rowMapper = new WorkFlowRowMapper(); rowMapper.setSqlUtil(this.sqlUtil); rowMapper.setIntClassType(2); list = jdbcTemplate.query(sql_getWFRouteByNode, new Object[] { nodeNo }, new RowMapperResultReader( rowMapper)); return list; } 使用数据库 正确地操作事务 1）如非业务必需，避免过大的事务，一个事务的时间应该受到框架的严格限制，一般为2分钟 2）如果操作的只有一个资源，不要使用分布式事务，那将大大加大系统的消耗，框架中已经有了明确的事务机制 3）如果不是业务必需，不要试图在业务代码中自己去控制事务，完善的系能框架已经给出了完善的事务处理机制 4）在一个好的系统框架中，事务的控制是依靠AOP来实现的,通过简单的配置就可完成事务的管理，但是要求需要被控制事务业务代码符合框架定义的代码规范。 使用数据库 不要试图通过查询得到所有数据 1）在做任何业务代码的时候，评估在未来生产环境中查询可能产生的数据量 2）因为是在多用户环境中，过多的数据量将不可避免的产生内存泄露，从而引发系统崩溃 3）当返回的数据量超过一定数量的时候，在我们的系统架构中给出的折衷值是400,必须进行后台翻页的设计 使用数据库 不要试图通过查询得到所有数据 SELECT A.SERV_GUID,A.SERV_ID,A.PRODUCT_ID,A.AREA_CODE, A.BILLING_NO,A.USE_CUST_ID,A.USE_TYPE,A.EXCHANGE_ID, A.INST_STATE,TO_CHAR(A.INST_STATE_DATE, YYYY-MM-DD HH24:MI:SS) AS INST_STATE_DATE,A.SLA_ID,A.REGION_ID,A.STATE, TO_CHAR(A.CREATE_DATE, YYYY-MM-DD HH24:MI:SS) AS CREATE_DATE,TO_CHAR(A.COMPLETE_DATE, YYYY-MM-DD HH24:MI:SS) AS COMPLETE_DATE, FROM SERV A WHERE ROWNUM lt; 400 使用数据库 ??尽可能优化查询 1）在模型设计的时候就考虑冗余相对不会变化的数据 2）如果涉及大数据量，在模型设计的时候考虑进行分区 3）涉及到有分区的表，查询语句一定要使用分区索引，否则即使适用了其他索引，也将导致全表扫描 4）尽可能将复杂查询简单化，不要关联太多的数据 5）能用业务组件组装的，尽量避免使用数据库的运算，应用服务器的计算扩展能力远远超过数据库服务器的扩展能力，虽然代码复杂程度加大，但是提供了后续的应用可扩展能力 6）如果有涉及到大数据量的统计，在模型设计的时候考虑中间数据，并在代码中实时维护这些中间数据 使用数据库 典型的查询优化案例 限于篇幅，我将打开一个Word文档对我们出现过的一些典型SQL性能优化问题进行讲述 各位同学和老师，晚上好，我是罗翔 * * 下面言归正传，切入我们今天晚上的主题 今天晚上的交流我