APP访问缓慢优化方案

• 摘要：现象公司的一个APP点击某些页面非常缓慢,有些等待1分钟,出现大部分用户不想使用的情况。目标要在3天内完成优化,越快越好。解决索引分析:某些跨表查询没有建立索引,虽然单表只有30万数据,但是一关联查询,特别是4、5张表关联时极其缓慢。解决方法:建立索引即可。缓存因为数据都从oracle数据库读取,我们首先想到的就是使用缓存代替。把全部配置表的数据放到Ehcache缓存中,不直接从oracle读取,提高效率。为何选用Ehcache?请阅读《缓存选型-Ehcache、memcac
• 现象

  公司的一个APP点击某些页面非常缓慢,有些等待1分钟,出现大部分用户不想使用的情况。

  目标

  要在3天内完成优化,越快越好。

  解决 索引
  1. 分析:某些跨表查询没有建立索引,虽然单表只有30万数据,但是一关联查询,特别是4、5张表关联时极其缓慢。
  2. 解决方法:建立索引即可。
  缓存

  因为数据都从oracle数据库读取,我们首先想到的就是使用缓存代替。把全部配置表的数据放到Ehcache缓存中,不直接从oracle读取,提高效率。

  • 为何选用Ehcache?请阅读《缓存选型-Ehcache、memcached、Redis》
  • 如何使用Ehcache?请阅读《Ehcache的一个完整例子》
  分页
  1. 发现有一个页面查询需要5秒,比较慢。发现其实结果集是379条详细记录,作了379次循环全部查出,一次显示。而实际上用户不需要一次观看379条记录,完全可以采用分页。APP页面每页只显示了10条,翻页时再查询下10条。这样立马1秒内能响应。
  2. 还发现有几个页面,查询条件里的时间默认是为空的,那样子用户点击查询默认就是查询全部数据,虽然这些页面作了分页,但是数据需要排序,把时间最靠前的先显示,这种情况下如果数据量上了30万以上,无论索引如何优化都是无法做到1秒内完成查询的。而实际上用户并不需要查询所有的数据,只需要把查询时间默认设置为查询最近2天,修改后1秒内完成响应。
  集群

  目前APP、后端服务都只部署在一个weblogic上,考虑到以后业务发展,用户数突增,需要考虑weblogic集群来进行负载均衡。目前主机有256G内存,足够运行,但在近期需完成集群优化防止性能下降再次造成用户不满。

  总结

  上述四种优化后,APP基本快速响应,用户使用还算比较满意,但其实,最关键的还是索引和分页的优化。

  • 缓存的优化不是没有作用,而是太小,oracle的查询其实已足够快速。我做了一个实验,结论是oracle查询一次16毫秒,第二次同样的SQL语句是0毫秒,而缓存也是0毫秒,所以非特殊情况下,基本没有任何优化效果。
  • 集群只是一个预防的措施,因此暂时来看作用不是很突出。