首先我们需要部署一个测试环境，将Web项目的源代码拷到测试环境Web服务器IIS上，使得可以直接通过IE访问我们的网站。SQL Server环境可以部署在同一台机器上，条件允许的话有专门的数据库测试服务器那当然是更好，没有也无所谓。部署完测试环境后保证我们这个测试环境没有其他用户在访问，只有我们访问，免得其他用户的操作影响了我们。
假设我们的网站在首页打开的时候很慢，需要10多秒钟才能打开，首页打开是调用了多个函数，函数中调用了多个存储过程，到底是哪个函数慢？到底是哪个存储过程慢？是Web服务器上的函数执行花费了大量的时间还是数据库中的存储过程执行花费了大部分时间？到底每个函数，每个存储过程各自花费了多少时间呢？这些问题就需要通过ANTS Profiler和SQL Server Profiler来解决。
使用ANTS Profiler和SQL Server Profiler进行瓶颈查找的过程如下：
（1）在Web服务器上安装并打开ANTS Profiler，在Profiler项目向导中选择Profiler类型为详细模式，如图所示：
（2）单击“下一步”按钮，出现要进行跟踪的应用程序类型，这里是将项目发布到IIS中的，所以选择第二个。
（3）单击“下一步”按钮，出现ASP.NET应用程序配置界面，设置应用程序起始页、.NET版本、IIS版本和要进行跟踪的端口。
（4）单击“下一步”按钮进入代码跟踪选择界面，选择将所有的.NET方法进行跟踪，也可以选择第一个选择，只对有调试文件和源代码的方法进行跟踪。
（5）这里我们要跟踪的是首页，所以一旦单击“完成”按钮系统就会打开IE浏览器载入首页，在单击“完成”按钮之前，需要对测试环境数据库开启SQL Server Profiler。SQL Server Profiler负责跟踪数据库上执行的脚本情况，建议将跟踪结果保存到数据库中，这样可以通过SQL语句来查找跟踪的脚本。将跟踪结果保存到数据库的配置如下图：
（6）对于跟踪事件，如果是进行简单的性能跟踪，则只需要选中RPC：Completed和SQL：BatchCompleted两个事件即可。至于关注的列，主要是关注TextData、CPU、Reads、Writes、Duration等列，其他列不用特别关心，采用默认选项即可，如图所示：
（7）单击SQL Server Profiler中的“运行”按钮，开始对数据库的跟踪，然后单击ANTS Profiler向导中的“完成”按钮，开启对ASP.NET应用程序的跟踪。
（8）系统将打开IE浏览器，提示输入有效的用户名和密码，过几十秒钟后，首页就可以完整展示出来了。SQL Server Profiler中也跟踪到了大量在首页载入时执行的SQL语句和存储过程。
（9）单击ANTS Profiler工具栏中的“获得快照”按钮，系统将会为ASP.NET应用程序建立快照，然后列出从运行开始到快照时刻系统中执行时间最长的方法和方法的源代码，如图所示：
（10）从上图中可以看到当前最长时间的一个方法是ViewMainQueryFGS.aspx.cs中的Page_Load方法，该方法花费了13.27秒，而具体花费时间的地方是在Page_Load方法中调用了BindTable方法。
（11）使用VS打开程序源代码，或者是在ANTS Profiler中，点击查看BindTable方法，我们可以看到该方法中有两个函数调用比较耗时，一个是378行，花费了11.1秒，另一个是38行，花费了2.14秒，如图所示。
（12）使用同样的方法可以查看到GetDataListBySQL方法具体调用了哪些方法，各个方法多少秒。这里通过查看源代码我们可以知道，该方法最终是调用了数据层中的p_cx_prodplanfinish存储过程，切换到SQL Server Profiler，我们可以看到系统调用该存储过程花费了10.98秒。
（13）现在我们再回过头来算一下，整个页面载入花了13.27秒（Page_Load方法的时间），其中光执行这个存储过程就花了10.98秒，显然，这个瓶颈是在存储过程p_cx_prodplanfinish上，首先应该对该存储过程进行优化。另外还有个2.14秒的地方调用了另外一个存储过程，也可以进行优化。
使用同样的方法，用ANTS Profiler和SQL Server Profiler就可以找出具体是哪个函数最耗时，耗了多少时间，哪个存储过程最耗时，耗了多少时间。确定了到底是应用程序消耗了大量时间还是存储过程消耗了大量时间，接下来可以有的放矢了。
