TA的每日心情![](source/plugin/dsu_paulsign/img/emot/kx.gif) | 开心 2023-1-5 00:48 |
---|
签到天数: 2591 天 [LV.Master]无
|
本帖最后由 老兵帅客 于 2012-7-25 12:20 编辑
0 }3 X4 P; b9 m+ C! ?
9 A! i, {; s) L( r3 J7 l( [刚刚解决了一个performance issue,事情是这样的,我们的一个项目所使用的一个web service是由我们公司印度分公司的员工,我们称之为offshore team,完成的,这个东西在测试服务器上工作没问题,但是发布到生产机以后遇到了严重的performance issue,因为客户的访问请求居然需要六到八分钟才能完成,届时客户界面那边早就time out了。客户要求offshore team解决这个问题,他们找了半天找不到原因,没办法这件事就交给我们来解决了。
# A6 H+ L. e }, P% p
% p; M+ T6 S# v8 d% v我找来代码,发现里面居然没有任何log语句,因此你无法通过log信息来发现问题出在哪里,这程序是怎么写的和测试的?没辙,咱自己来给它加上所需要的log语句吧,然后安排重新发布到生产机上去。说到这里有人可能会问,你怎么不先在测试机上测试而直接上生产机了呢,回答是这程序在测试机上没问题,而在生产机上有问题,那唯一的可能就是数据量导致的问题,因此发布到测试机没用,还是直接上生产机吧。
7 A+ b: X# ~+ H U& R. M3 d* z0 k0 T8 r! Y; `, V3 J
发布到生产机上,安排客户进行测试,发现问题出在了JDBC语句上,这句话用字段值来搜索所需要的记录集合,数据库表里面对应字段类型是varchar2,而我们的offshore家伙们的对应JDBC PrepareStatement语句居然是setLong,这样每个记录都需要做一次数据类型的转换,这么干数据量小的时候没事,一旦大到了一定程度,这性能能不完蛋嘛。4 F e- ]. h2 s5 t/ J
- Y6 q7 i, |* f6 X2 J( A发现了问题,解决方案也就简单了,在java程序里面预先转换好数据类型,然后把setLong改成setString,再把程序重新发布到生产机上去再测试,这回好了,从原来的需要六到八分钟减少到不到一秒钟,完事了。
7 [' `: c1 z% v
" i/ D3 R5 @3 |% [0 ^+ z3 k/ l+ ~/ Yoffshore team这帮家伙水平也忒次了,居然不懂得要尽可能减少数据转换次数这个基本常识,从而导致了这次的性能问题。出了问题自己还没办法解决,只好求助加拿大这边的人来帮忙,这样的out sourcing有什么实际意义呢。 |
|