TA的每日心情 | 开心 2023-1-5 00:48 |
---|
签到天数: 2591 天 [LV.Master]无
|
本帖最后由 老兵帅客 于 2012-7-25 12:20 编辑 4 h, c3 p& J; l, l" M( {5 y
" w( m! Q2 A9 d' R
刚刚解决了一个performance issue,事情是这样的,我们的一个项目所使用的一个web service是由我们公司印度分公司的员工,我们称之为offshore team,完成的,这个东西在测试服务器上工作没问题,但是发布到生产机以后遇到了严重的performance issue,因为客户的访问请求居然需要六到八分钟才能完成,届时客户界面那边早就time out了。客户要求offshore team解决这个问题,他们找了半天找不到原因,没办法这件事就交给我们来解决了。+ A9 l6 e$ T- E# l+ a7 p3 }: u
" I$ D3 x% M3 E; T5 v. U7 E" |我找来代码,发现里面居然没有任何log语句,因此你无法通过log信息来发现问题出在哪里,这程序是怎么写的和测试的?没辙,咱自己来给它加上所需要的log语句吧,然后安排重新发布到生产机上去。说到这里有人可能会问,你怎么不先在测试机上测试而直接上生产机了呢,回答是这程序在测试机上没问题,而在生产机上有问题,那唯一的可能就是数据量导致的问题,因此发布到测试机没用,还是直接上生产机吧。- v( k, E1 ]( `/ T
0 H" ], B2 }9 u( q" x# Y8 W发布到生产机上,安排客户进行测试,发现问题出在了JDBC语句上,这句话用字段值来搜索所需要的记录集合,数据库表里面对应字段类型是varchar2,而我们的offshore家伙们的对应JDBC PrepareStatement语句居然是setLong,这样每个记录都需要做一次数据类型的转换,这么干数据量小的时候没事,一旦大到了一定程度,这性能能不完蛋嘛。
0 k) D) {- J& u# f' e: Y7 u5 J9 X! n; H# c
发现了问题,解决方案也就简单了,在java程序里面预先转换好数据类型,然后把setLong改成setString,再把程序重新发布到生产机上去再测试,这回好了,从原来的需要六到八分钟减少到不到一秒钟,完事了。
+ B1 o @& ?, P/ R4 R$ e! I6 P' h' B- n
offshore team这帮家伙水平也忒次了,居然不懂得要尽可能减少数据转换次数这个基本常识,从而导致了这次的性能问题。出了问题自己还没办法解决,只好求助加拿大这边的人来帮忙,这样的out sourcing有什么实际意义呢。 |
|