鲍勃推动的新订单程序上线后，系统变慢。董事会担心因此影响生意和声誉。鲍勃费尽周折查出原因在后台数据库，然而在测试环境下却没有什么不正常的。鲍勃最终能解决系统变慢的问题吗？
在鲍勃的推动下，公司的订单系统经历了一个非常快速的开发流程，很快就集成到在线店面中去了。不久，他发现，销售系统的运行有些异常：查询每条在线订单的时候，前台Web服务器从后台数据库中读取数据的时间徒然上升，而且容易出错，响应客户请求方面也显得缓慢。
与此同时，当Mira（鲍勃的新同事）开始为电子商务程序更新模块时，系统终于不堪重负，倒下了。鲍勃和Mira感到了压力：董事会担心，因为系统缓慢，一些用户会散播谣言，使公司的信誉度下降，以至会影响上市的进度。
为什么我们把系统放在生产网络中，大家都用得很好的时候，系统却变慢了？鲍勃想改变这个系统越用越慢的情况，他该如何做呢？
根源在后台数据库
由于鲍勃曾经管理过比较复杂的网络系统，他知道，用户反映系统出现故障时，一步一步去确定系统的各个环节是否有问题非常麻烦，有很多工作要做：检查交换机和路由器，Ping操作系统，检查数据库服务器，检查数据库是否正常（如日志已满），检查IIS及App Pool是否异常，检查自定义的Socket程序是否正常等等……
鲍勃订购了System Center Operation Manager 2007 ，这样可以通过自定义分布式应用程序，把所有应用程序整合在一起，系统会自动监控每台服务器的工作环节。如果有问题，系统会及时让整个工作小组的开发和维护人员同时收到通知。但时间紧迫，董事会并不允许他等到这个新产品上线。
在确定排除了Web服务器CPU和内存可能存在的瓶颈之后，针对Web服务器上的IIS 6.0 ，鲍勃要求开发小组改写了三个Monitor脚本，其中使用两个Monitor脚本收集系统信息：IIsmDyn.js和IIsmStat.js。以IIsmDyn.js脚本为例，这个脚本可以检索系统性能信息和系统事件信息，这样可以避免维护人员通过手工访问性能监视器或事件查看器。该脚本会检索来自以下源头的事件查看器条目：WAS（Web 管理服务）、W3CTRS（World Wide Web 计数器）、W3SVC（World Wide Web 发布）等。
工作小组重新利用压力测试软件对Web服务器上的静态页面进行测试。监控脚本在Web服务器上布控了3天零19个小时，几次测试的结果都表明，每台服务器的处理能力都维持在每秒80.20次请求的级别上，CPU的利用率约为65%左右，这相当于2100～2500名并发访问用户的情况。但是监控脚本中并没有直接提供警告的信息，人们带着怀疑的心理对后台数据库进行性能测试。刚一开始，服务器就缓慢下来，鲍勃和Mira的眼睛都盯在后台数据库服务器上了。