在软件开发过程中，写出影响性能或者有BUG的代码，都是我们无法回避的现实问题。

　　不过，如果能够在程序发布前（自测或者测试阶段）将这些问题找出来，我想大家都是可接受的。

　　今天就来介绍一种方法，用来发现在网站开发过程中，容易被我们忽略的一些问题，而这些问题其实是容易被发现的。

　　将要介绍的方法需要使用Fiddler这样一款工具，我将演示如何使用Fiddler来发现404错误，以及较大的响应输出问题。

　　我认为这二个问题实在太低级了，所以我设计了这个方法，并写了这篇博客，希望大家能喜欢。

　　我发现，许多人对于这二类问题（404错误和较大的响应输出）都很不在意，好像它们根本不会对一个网站有任何影响似的。

　　难道真是这样吗？

　　我认为：如果你做的网站程序，用户访问量很小，或许的确可以忽略它们。

　　否则，我还是建议你应该纠正它们，下面我来解释它们的危害。

　　404错误

　　我一直认为404不仅仅只是一个数字，过多的404也会影响程序的性能。

　　通过对404错误的分析，我发现多数的404错误都与一些资源文件的引用有关，比如代码中引用了不存在CSS或者JS文件，这些404错误发生时，可能并不会影响页面的正常显示，因此，这类错误根本就不会引起一些开发人员的注意。

　　再加上，许多人又喜欢复制粘贴，导致这类错误越来越多。

　　为什么我会说【过多的404错误也会影响性能】呢？

　　因为当404错误产生时，IIS其实并不只是返回这样一个数字，而是一个完整的HTTP响应，响应的内容是一个正常的网页。

　　不同的IIS版本的这个404的错误页面长度并不相同，IIS6默认的404错误页面长度超过2K，而IIS7.5的默认错误页面会超过8K 。

　　虽然这个响应看起来并不大，但是由于请求不成功，每当打开这些页面时，请求会重新发起，数量会越来越多。

　　反过来，我们可以想一下：如果要引用的资源文件存在，这些文件仅仅需要请求一次，浏览器就会缓存它们，根本不需要每次都重新发起请求。

　　这样一来，客户端减少了请求数量，服务器减轻了连接压力，那些无意义的404响应所浪费的网络流量也能消失。

　　因此，过多的404请求简直是一个恶性循环，它延长了页面的显示时间（前端），给服务端带来了连接压力，也浪费了网络资源。

　　较大的响应输出

　　较大的响应输出，应该是容易理解的，那就是：服务端返回的结果太大了。

　　我们可以想像一下【较大的响应输出】意味着什么。

　　1、浏览器显示一个【很大的网页】，是不是会比较慢？

　　2、【很大的网页】是不是会花费较长的网络传输时间？

　　3、服务端生成【很大的网页】，是不是也要花较长的生成时间？

　　4、如果这个【很大的网页】的结果来自于数据库的查询结果，会不会给数据库也带来较大的压力？

　　产生这种情况就典型的场景可能由于一条SQL查询引起的： select * from XXX wherename=@name

　　或许在早期阶段，XXX表的记录很少，或许当初在设计时根本没想到name会存在一大堆的复制数据时，再或者，当在本地环境测试时，网速根本不是问题，而浏览器的渲染速度的延迟又没有被发觉时。

　　我们可以想像一下：这样的程序如果部署在互联网上运行，结果会如何？

　　关于【较大的响应输出】，还有二个可能发生的场景：

　　1、往ViewState中放入一个很大的对象。

　　2、展示一个树形结构，或者是一个没有where条件的查询（都属于不分页情况）

　　当以上这三类情况发生时，你认为性能还能接受吗？用户还会满意吗？