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