优化小结及心得

2013年12月份，对系统的首页做了一些性能优化的工作，仅仅是从代码方面，服务器方面的没有涉及到。

使用google浏览器的调试模式查看。

优化之前，首页的加载时间在3.7秒左右。

优化之后，首页的加载时间在0.7秒左右。

优化主要工作分为两块：

一、页面代码处理。

第一步：由于首页是由多个页面构成的，像是框架一样，一个总的页面，划分几个区域，每个区域include一个页面，各个页面都有一些对JS等资源文件的引用，对于这些不会发生改变的静态资源，统一放在最外层的页面上引用，最外层的这个页面在不刷新浏览器的情况不会刷新，这样就节省了JS的加载时间。

第二步：对各个页面上的JS代码进行处理，属于变量或方法声明的，统统移到外层的JS文件中。

第三步：有一块内容是加载一个地图的flash文件，地图中显示的数据从后台获取，之前的做法是请求好数据后再生成flash文件，现在改为先构建一个空数据的地图，把flash地图先显示出来，使用ajax请求后台数据，得到数据后再为地图设置数据。

第四步：首页上共有两处地方使用了<s:action>标签，该标签的请求是同步的，当没有收到后台返回数据时，页面不会显示出来，所以都改为了ajax异步请求。

以上的处理，页面的显示速度明显加快了许多，虽然数据全部返回的时间没有改变，但页面的各个组件都能先显示出来，对于用户体验有很大的提升。

二、后台逻辑和SQL处理。

优化了程序，由于对于重构还只是一知半解，在高手提供的SQL帮助下，对for循环进行了处理，使用分组查询。

这里顺便记录一下其它同事对列表的查询进行了优化，在数据量大的情况下，列表页面的显示使用数据库的rowNum，也就是物理分页的方式进行查询，有效的提高了查询速度，如果带有表的关联查询时，使用left join 的时候，根据场景的应用，可以考虑先使用物理分页，缩小需要连接查询的数据范围，但对于部分排序查询没什么作用，只能根据排序的条件调用不同的SQL。

三、分层处理数据，尽可能的把数据放在离用户最近的地方。

这里是同事优化后分享的经验和做法。主要思想是，把需要提供给浏览器的数据提前准备好，主要有几种做法：

首先是建立有效的索引，在实际开发中，虽然很多地方都用到了索引，但并不是所有的索引都是高效的，有些甚至不如不使用索引直接查询，可以通过数据库的执行计划进行分析，对花费时间及CPU使用情况等相关参数确定索引的建立。

其次是使用缓存，缓存分很多种，前面提到的在最外层页面加载JS等资源文件，就是浏览器缓存的一种应用，通过开发者工具可以看出，从服务器取回的状态是200，使用缓存的话，状态会是304，表示没有被修改的。我们系统中用到了memcached缓存，但是通过缓存监控发现，缓存的利用率非常低，对于很多实时性要求不高的数据都可以放入缓存，把缓存充分的利用起来。数据库也有缓存，这一块内容不是很了解，以后掌握了再来更新吧。

再次，根据不同的需求和场景，可以考虑把底层的数据进行预处理，存入另一张表，在新表的数据量不是很大的情况下是可行的，基本上所有的底层表数据量都比较大，而前端页面上需要的数据还需要对底层数据进行一定的处理之后再显示，对于历史数据或不会发生改变的数据，完全可以预处理一下，我们是通过JOB，在系统资源空闲的时候运行，去生成新表的数据，当请求数据时，直接从新表中取出预处理过的数据，这样的速度就会得到提升，一些使用了图形组件之类的展示页面，也可以通过类似的思路，生成静态页面来显示。

性能测试工具：目前使用AB测试。

心得：

把JS代码的声明放在不太会刷新的页面中引用，尽可能避免由于重复加载JS文件造成的浪费。

合理使用异步请求，减少因请求数据时间过长对用户造成的等待影响。

程序中尽量少使用for循环，尽量使用sql分组查询。

考虑多次请求数据库简单查询和请求一次数据库复杂查询的总体效率。

在场景允许的情况下，尽量把数据放在离用户最近的地方，尽量把数据整合成最接近页面展示的结构。