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