清华大学仪器共享平台性能优化实践

梁思率, 王　臻, 杨树国

(1. 清华大学 计算机与信息管理中心, 北京　100084； 2. 清华大学 实验室与设备处, 北京　100084)



清华大学仪器共享平台性能优化实践

梁思率1, 王臻1, 杨树国2

(1. 清华大学 计算机与信息管理中心, 北京100084； 2. 清华大学 实验室与设备处, 北京100084)

清华大学仪器设备共享平台在学校提供的负载均衡硬件架构F5以及开源负载均衡软件架构shiro + ehcache + quartz的session同步、缓存同步、定时任务分布式调度管理下,综合运用各种数据库优化技术、服务端优化技术、前端优化技术提升了系统访问速度。实践证明,这套方案是有效的。

仪器设备管理; 负载均衡；物化视图； SQL优化

清华大学仪器设备共享系统的用户数量级是5万个左右,包括来自校内200多个实验室的用户以及部分校外用户,管理大型仪器设备数千台,每年要进行一次设备效益评价统计工作。此外,还要开发手机端应用,以满足未来更多用户的需求。因此,对系统性能的要求就提升到了一个很重要的层面。不同于一般业务系统,它要求快速响应,对于大数据的处理和查询要做到尽可能实时,是一个典型的性能优化案例。通常,负载均衡是一个好的策略,此外,还要根据性能瓶颈的来源,逐个进行优化。

1　Web系统响应时间模型

我们主要对Web系统进行优化,这里面比较重要的指标包括响应时间、吞吐率、资源利用率等。响应时间是其中最重要的一个指标,它直接面向用户,关系到用户体验。对于一个等待时间较长的页面,用户是没有耐心去使用的。因此,我们先对响应时间建立模型[1-3]:

(1)

T表示系统响应时间由网络传输时间Tweb、客户端响应时间Tc和服务器响应时间Ts3部分组成。对它进一步进行细化得出影响因子模型如下[4]:

T≈payload/bandwidth+RTT×n/portNum+

(2)

其中：payload是数据传输量,bandwidth是网络带宽,它们是Tweb的部分；RTT是网络延时和建立连接耗时,n是资源请求数量(这里的资源指js、css、image等静态资源),portNum是并行端口数,T渲染是页面渲染时间,它们是Tc的部分；Nvu是每台服务器的并发用户数,Tsql是数据库操作耗时,Tserver是服务器缓存及代码的执行时间,它们是Ts的部分。这就为我们进一步优化提供了依据。

由公式(2)可见,Tweb部分的bandwidth是由网络环境决定的,它不由我们控制,在清华大学采用的就是清华校园网,而payload部分是可控的,我们可以通过压缩静态文本资源、压缩图片、设置浏览器缓存的方式减少数据下载量,相关优化技术可参考前端优化。

Tc部分的RTT可通过设置HTTP的Keep-Alive功能加以减少,n可通过合并js、css文件、将小图片集成到一张大图中的方式加以减少,portNum和浏览器解析域名有关,一般不加以调整,T渲染可通过页面静态化技术、ajax技术加以减少。

Ts部分的Nvu可通过负载均衡技术加以减少,Tsql可通过各种数据库优化技术加以减少,Tserver可通过服务器缓存、程序代码优化技术、前端计算代替服务端计算的方式加以减少,此外,Tsql和Tserver还可以通过跟踪用户使用习惯有针对性的加以优化。

2　负载均衡

对于分布式文件存取和数据挖掘一般采用计算集群,如spark,而对于高校内部的业务系统一般采用Web集群,如开源的shiro + ehcache + quartz框架,或者商业的Terracotta框架。由于预算的原因,我们采用的是开源框架。其中,集群缓存同步策略是采用Ehcache[5-8],关于它的配置已经有了大量的说明。而集群定时任务调度则是采用Quartz[9],它可以避免重复执行已经执行过的定时任务,同时保证定时任务均匀地分配到各台服务器上,达到负载均衡,关于它的设置也有说明。而用户session同步则是采用Shiro权限框架,通过一定的spring配置,将session放到Ehcache缓存中进行管理,而Ehcache是有集群同步策略的,这就使session也实现了同步。

由于会话保持技术的存在,一个用户一般只能登录一台服务器,除非长时间登录,否则session同步在大部分时间里是不需要的。此外,如果没有在用户之间共享全局缓存读写,缓存同步也是不需要的,只需要定期从数据库同步即可。对于这样的系统,一般只存在定时任务的同步,如果单独上一个quartz框架可能需要在运维的时候按一定顺序执行不同服务器上的不同java函数,这样的操作是繁琐的,有一种替代的办法是读写配置文件,不同服务器设置不同的开关参数,控制定时任务的执行与禁止,使得定时任务只被一台服务器执行,而损失的只是负载分配和调度的功能,这对少量的服务器集群(2～4台)是可以接受的。

3　前端优化

3.1压缩图片、css、js文件的大小

文本资源压缩一般采用Gzip算法,这在传输时可以节省大量的带宽,对于图片、文件、css、js都可以采用这种方式传输,此外还有将多张小图片集成到一张大图,尽可能传输压缩后的小图而让大图在详细页展示,用工具将js进行压缩和混淆,精简合并css等[4],这已被谷歌等互联网巨头大量采用,并且已成为前端开发的流行规范,有助于降低浏览器加载时间。

3.2页面静态化

这和缓存的思路是类似的,对于经常访问但又变化不大的页面,如果内容较多、有较多的数据库访问,则采用页面静态化并定期更新不失为一个好的思路,这可以减少浏览器渲染的时间。

3.3Ajax

Ajax技术是一种比较成熟的技术,对于我们开发的前端系统,基本90%以上的服务器访问都是采用这种技术,除了少量的大表单提交。局部刷新技术可以有效缓解页面刷新带来的数据传输压力,减少了数据传输量,降低了网络传输时间。

4　Java程序的优化

除了负载均衡框架保证了分布式系统逻辑上的正确性,以及多个服务器带来的性能提升以外,对程序本身的优化也是非常重要的。对于Java后台程序,常见的优化措施有很多种,对程序的编码要求也很高,经过我们测试,真正影响性能的有如下几种。

4.1缓存

我们在判断上机预约权限(也包括送样预约和直接登记预约)的时候采用了大量多维度的权限验证,这些验证操作要访问大量的数据库,如查黑名单、白名单、仪器规则设置、实验室规则设置、校内外主用户余额等,如果能将这些计算提前计算好放在用户session里,或者一次计算处处采用下次判断能从session里及时获得以前的计算结果,则性能将大大提升。实际上,我们是将一部分权限计算放在了登录环节,还有一部分权限计算虽然放在了各个权限判断的调用函数里,但都做了session缓存,下次同一个用户再进行预约的时候就不需要重复进行计算了。此外,在某台仪器的预约日历载入的时候,一般我们是从数据库一次性载入1周的日历,数量级在500个左右,有时用户量大的时候每个人都做这样的操作,会导致性能下降。我们可以做一个启动定时任务,将所有仪器设备(大约2 000台)的当前周日历全部放在缓存中,当周切换的时候及时更新这些数据,如果有用户做了预约的增删改查操作也及时地更新缓存里的数据,这样就可以使性能提升。而需要注意的是在集群下一定要做缓存同步,避免数据不一致。

4.2For循环

For循环是一个很容易被人忽略的环节,而这个地方往往是大量消耗性能的。比如在For循环里再写sql、new变量、反复调用同一个函数而不是将它的返回结果提前储存起来等等。循环写sql是非常消耗资源的,应极力避免,一般得通过一定的转化变为一条sql。循环New变量是一个编程习惯问题,会导致GC大量的被调用最后造成内存溢出,类似不关闭connection、不关闭io这样的问题,应统一放在循环外面,只调用一个变量。循环中用到的重复函数结果也应该提前存储在变量里,避免额外的开销。此外,try-catch模块也不能放在循环里,必须放在外面。总之,对循环的优化是java优化的重要环节,毕竟它涉及到复杂度的问题。

4.3前端计算

我们可以把大量繁琐的计算放在前端js里,即富客户端,让每个客户的浏览器去执行,这有效的缓解了服务器的计算压力,这种优化方式跳出了纯粹优化服务端的思维定势,是一种比较有效的办法。比如日历控件的月、周、日视图切换就可以采用这种技术,服务器1次加载1个月的日历,由前端浏览器js根据当前视图时间范围决定显示的范围。

4.4跟踪用户使用习惯

在我们还不太了解用户使用习惯的时候需要采用一定的办法去实时地跟踪用户的使用情况[9],这样可以做到有的放矢,有针对性的优化那些热门的模块和功能。我们采用的是用一个filter拦截器记录所有的用户访问url次数和执行时间,对于桌面端和手机端都做这样的跟踪,从中我们可以看出哪些是需要马上进行优化的,哪些使用的用户量少可以先放一放。此外,对于Java内存泄漏还可以采用Jprofiler工具进行跟踪,压力测试可以采用开源的Jmeter或者商业的Loadrunner工具进行。

5　数据库的优化

数据库优化则更是一个被讨论了无数次的话题[10-12],但真正能用好却不容易,我们在实践中总结了以下几点,作为重点考虑的策略。

5.1物化视图

有一种特殊的视图是物化视图[2],它可以生成物理表,当引用的表数据有更新的时候,它也可以触发更新,或者定时更新。对于数据变化量不大而又有大量联立操作的视图比如人员、仪器、定制的组合列表页面等,可以采用物化视图。物化视图的sql语句并不复杂,一般10个以内的物化视图都不会影响数据库性能,这就大大降低了我们系统的数据库负载,提高了访问速度。

5.2分割历史表

在高校往往积累了10几年的业务系统数据,这些数据在io的时候不可能从所有的数据中进行查询,而要区分最新数据(当年或当月)和历史数据,分别存放在不同的表内,这样才能提高检索性能。对于预约数据也得采用这样的策略,当历史数据积累得多了以后,比如10年以上,对数据的检索就必须采用历史表和当前表的方式。

5.3取消联立大表

视图或sql中往往无意识地联立了一些大表,比如人员表(清华有几十万人员的历史数据),有时还联立了不止1次,比如预约视图调用了从用户的联系方式和主用户的联系方式。这些相对不重要的数据可以在页面端实时获得,比如通过点击ajax展示详细页获取联系方式,这种时间上分散加载的方式也能大大提高系统性能。

5.4设置冗余字段

对于人员数据、仪器数据这样的字段每个表几乎都要用,如果都采用联立的方式获得势必造成大量的数据库性能消耗,因此对于较稳定的字段比如用户名、用户姓名等可以作为冗余字段放在表里,而不需要再去联立获得了,虽然这不符合数据库范式,但却提高了系统的相应速度,是一种灵活的策略。

5.5设置索引

索引的重要性毋庸置疑,对于where语句、连接语句中大量用到的字段要做索引,索引的总数每个表不易超过5个,但这也不绝对,对于有大量字段的复杂表一般我们最多使用6～7个应该也没有问题。对于会绕开索引的sql语句要极力避免,比如is null/is not null要用非空或default字段代替,or要用union代替,<>要用>或<代替,尽量少用like和sql函数,因为它们不会使用索引。

5.6避免*查询

这是一个经常被忽略的问题,但是在实际应用中我们发现,它造成了很大的性能损耗。比如我们的预约表有40多个字段,用*查询会大量消耗性能,如果只对需要的字段单独构造视图,则会减少好几倍的查询时间。

5.7SQL优化

对于sql优化的讨论已有大量的说明,而在我们的系统中应用也起到了立竿见影的效果。比如统计模块,需要从多个维度、多个角色、多个字段对一个主题进行统计,这时查询的性能就显得尤为重要。否则一个统计操作就需要好几分钟甚至1小时,就不符合系统的需要。统计主要是面向系统管理员、实验室管理员、仪器管理员、主用户、从用户查阅自己管理范围的数据汇总或测试记录明细。系统的难点在于要同时返回针对多个查询项(仪器、实验室、主用户或从用户)的几十个数据汇总时,交叉起来可能会到上万个数据量级的计算结果的获得。为了减少查询时间,在写sql的时候尽量用一条sql语句返回多条结果,包括多个查询项的和多个数据汇总项的结果,可以多用group by,在遇到实验室继承的情况时还得巧用start with,避免递归循环次数过多,可以将每次查询时间控制在几秒以内。对于继承或非继承、不同的角色和汇总/明细的组合、开始时间和结束时间约束的组合还得写多份sql。这里面涉及到很多sql组合的技巧,只能在实践中慢慢体会,而比较基本的包括:用exists替换in、where语句将缩减范围作用大的放在前面、直接用字符串名称定义规则代替递归查询、用group by代替distinct等。

6　应用效果和结论

采用了负载均衡和各种前后端优化技术后的清华大学仪器设备共享系统性能有了很大提高。我们对系统架构进行了升级,使得其能够支持缓存和session同步,以及定时任务的分布式调度,满足了大部分的要求。进一步根据业务系统开发积累下来的经验,对程序代码进行了深度优化,主要包括Java后台程序和数据库操作两个方面。经过我们的优化,系统各个模块能够顺利运行,并且绝大部分都能在短时间内返回应有的结果,提高了用户体验。这也便于进一步的手机端开发等需要快速响应的场合,在什么都需要短平快的今天,仪器共享系统也通过它的不断实践朝着这个方向迈进。

References)

[1] 张红光. 基于软件性能测试的Web系统响应时间优化研究[D]. 北京: 北京林业大学, 2010

[2] 刘乃嘉, 彭宇, 王鑫, 等. 清华大学网上选课性能优化研究与实践[J]. 实验技术与管理, 2011, 28(5), 247-278

[3] 王鑫, 苗春雨, 袁芳. Web应用性能评测的研究与应用[J]. 实验技术与管理, 2008, 25(8), 15-19.

[4] 王成, 李少元, 郑黎晓, 等. Web前端性能优化方案与实践[J]. 计算机应用与软件, 2014, 31(12), 89-147

[5] 苏昊. JavaEE网站性能优化技术研究[D]. 北京: 北京邮件大学, 2014

[6] 宗莲松, 潘华, 肖毅. 可扩展式教务信息系统的设计与实现[J]. 实验技术与管理, 2010, 27(12), 128-132

[7] 李社河. Apache shiro集群实现 [EB/OL]. (2015-04-23). http://blog.csdn.net/ lishehe/article/details/45218251.

[8] 刘柄成. 深入探讨在集群环境中使用 EhCache 缓存系统[EB/OL]. (2010-04-01). http:// www.ibm.com/developerworks/cn/java/j-lo-ehcache/.

[9] 百度文库. Quartz集群配置[EB/OL].(2012-04-03). http://wenku.baidu.com/.

[10] 老K. 数据库性能优化一:数据库自身优化(大数据量)[EB/OL].(2012-12-25). http://www. cnblogs.com/AK2012/archive/2012/12/25/2012-1228.html.

[11] 老K. 数据库性能优化二:数据库表优化[EB/OL]. (2012-12-28). http://www.cnblogs.com/ AK2012/archive/2012/12/28/2012-122802.html.

[12] 老K. SQL索引一步到位(此文章为“数据库性能优化二:数据库表优化”附属文章之一)[EB/OL].(2013-01-04). http://www.cnblogs.com/AK2012/archive/2013/01/04/2844283.html.

Practice of performance optimization for Tsinghua University instrument sharing platform

Liang Sishuai1, Wang Zhen1, Yang Shuguo2

(1. Center of Computer and Information Management, Tsinghua University, Beijing 100084, China;2. Office of Laboratories and Facilities, Tsinghua University, Beijing 100084, China)

Tsinghua University instrument sharing platfom uses F5 as load balancing hardware architecture and shiro + ehcache + quartz as load balancing software architecture, which realizes session synchronization, cache synchronization and timed task distributed scheduling, and uses all kinds of database, server and client optimization technology to promote the access speed. This scheme has proved that it is effective in practice.

management of instruments and equipment; load balancing; materialized view; SQL optimization

DOI:10.16791/j.cnki.sjg.2016.04.066

2015- 09- 06

梁思率(1984—),男,浙江杭州,硕士,工程师,研究方向:高校信息化.

E-mail：liangss@tsinghua.edu.cn

G482；TP311.1

B

1002-4956(2016)4- 0235- 04