●Vamshidar Rawal 的缺陷
现象:
我们将代码设置成在特定的跟踪页面运行时标,以自动检测实际最终用户在站点下载所用的时间(7*24小时)。结果显示无论是否是高峰时期或周末,下载时间能控制在限时 20 秒之内的概率只有 25%。我们对此束手无策,找不出其中的原因,这对于我们最终用户的使用体验无疑是一种打击。
原因:
我们几个月后才开始理出头绪。通过一段时间对网站最终用户实时使用情况的观察,竟然发现一个月内会出现两个特殊时间段,在这两个时间段内下载时间会由原先的 20 秒下跌至 5 秒。这一现象引起了我的注意,是什么导致了这两个特殊时间段的产生?在这两个时间段内发生了什么?后来终于得知在这两个时间段内,我们会进行半个月一次的网站更新,加入新的内容或代码。在这期间,我们的操作团队会占用一半的服务器资源,直至更新完成。而就在这个时间段内,长时间的下载问题也得到了解决。我们惊奇地发现在只有半数的服务器工作的情况下,网站竟然运行得更好。
问题:
◆ 最终,大多数的迹象指向了真正的问题所在:唯一的 OLEDB 连接字符串数量,它自创建之初就一直位于前端访问服务器上。
◆ 我们有 42 个前端访问(FE)服务器对应 28 个后端访问(BE)服务器,共包含 47 个语言数据库(DB)。
◇ 所以每个 FE 服务器都须创建并一直使用唯一的 DB 连接字符串,则唯一的 DB 连接字符串的总数量可达 28*47 = 1316 个。
◇ 问题是这个唯一的连接字符串的总数量远远超过了限定值(约 100 个)。
◆ 在网站更新期间,FE 服务器对应的 BE 服务器的数量缩减到原先的一半(21 个 FE 服务器对应 14 个 BE 服务器,包含 47 个 DB)。
◇ 这也使唯一的连接字符串的数量减少了一半(14*47 = 658 个)。
◇ 同时也提高了网站的性能,将原先 20 秒的延时缩短为 5 秒左右。
结果:
这驱使我们不得不对 FE 和 BE 服务器进行重新的布局和连接,以减少连接字符串的数量。我们最终决定在 FE 和 BE 服务器中间新增 6 个服务器,来解决连接字符串超限的问题。
◆ 现在我们有 42 个 FE 服务器 — 6 个搜索网络服务器 — 28 个 BE 服务器(47 个 DB)。
◆ 每个 FE 上的连接字符串数量递减为 42 * 6 = 252 个。
◆ 下载时间长的问题也彻底得到了解决,无论何时都能达到亚秒级标准。
经验总结:
网站发生的问题不可能被完全模拟,且几乎不容易排除。
必须考虑到实际工作环境的每个方面。
如果没有考虑周全,工作环境的任何部分都可能,且必将影响到网站的性能和最终用户体验。
●Xu 的缺陷
自从我笔记本的内存由 1GB 提升至 2GB 后运行得一直很好,直到我发现有时会出现 XP 不能响应我的休眠请求,不能关闭的情况。它会一直处于“保存个人设置”的状态。有一天我在没有完全确认它完全关闭的情况下,就把它放入了电脑包。半小时后,当我再次取出它时,它竟然热得烫手。我打开它,发现电源仍未用完。所以我猜测它的电源是处于关闭状态的。庆幸的是,功能未受到影响。但是我又担心它那么热容易被烧坏。尽管我在网上一直搜索相关信息,且安装了一些包试图想解决之一问题,可是始终不管用。
●Scott Banning 的缺陷
一年半前我发现我们的产品会存在这样的问题:当用户使用特定场景处理边界线时,更新不能同步进行。客户也反映过类似的问题。但是我们的产品快发布了,如果要修复这一缺陷,势必会打破现有的平衡,需要再进行大量的返工,且客户的反馈也不多,所以我们暂且把它搁置了,标记为未修复。大约一个月后,我再次激活它,并指出客户的反馈,但最终还是未修复。至今这个缺陷仍有待解决。这个缺陷一直让我感到非常沮丧。
原文出处:http://blogs.msdn.com/micahel/
(未完,精彩待续)
版权声明:51Testing软件测试网及内容提供者拥有本文全部版权,未经明确的书面许可,任何人或单位不得对本文进行复制、转载或镜像,否则将追究法律责任。
相关阅读: