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