构建高性能的ASP.NET应用（三）-从监控出发，让一切用数据说话

在上两篇文章中，我们已经给大家分析学习技术的一些思想，那么从本篇开始，我们就进入性能分析的环节。

这里又一点需要说明的就是，我们本系列的主题是“构建高性能”，但是我们会从“调优”开始，讲述如何一步步的分析性能瓶颈，然后优化，之所以按照这个方式来讲述的具体的原因，我们在第二篇文章中说过了。

其实说到调优，已经不是什么“高深”的话题，但是确实只是少部分人可以做的，因为它对很多的方面都有要求，例如软件，硬件，网络，开发底层等等。

一般而言，在进行调优的时候，绝对是不能“凭感觉”，也不能随随便便，很多情况下，我们之所以要调优，就是要“求火”，要快速的解决项目中的性能问题，所以，在时间和资源上面都是无法容忍做“无用功”的。

在进行调优的时候，我们一定要从事实出发，用数据说话。通过分析数据，然后一步步的找出症结点。

用数据说话，首先就要对我们的应用程序进行监控。

其实说到监控，朋友们也不用想得那么的复杂。但是到底监控什么要清楚。也许有人说我这个问题就是废话，但是实际的情况就是很多人胡乱的在监控。其实监控的实现不是太复杂，例如我们可以写代码监控应用程序的各个方面，我们也可以借助第三方的软件来监控等等。之所以要监控，就是为了后续出现问题的时候便于分析，所以，一定要收集“有价值的数据”，否则就是浪费资源，而且产生很多严重的问题。在我做性能优化的时候，发现很多的客户（公司）他们确实有监控，但是监控最后起到的价值不大，很多的时候，因为不恰当的监控把应用程序，服务器等都折腾死了。

可以看出，实现监控的只是利用工具而已，但是监控什么才是关键，也是我之前反复强调的思考力的问题，脑子一定要清楚。

我们可以这么来想问题，监控，其实就是收集应用程序运行的一些信息，说的更加的通俗一点，就是想知道应用程序是否在正常的运行。那么，什么叫做“正常运行”？就是应用程序本身，和它所依赖的环境，资源都是正常的。

那么应用程序依赖什么资源？从大的方面来说，就是软件和硬件呗。进一步的想，软件部分包含哪些部分？操作系统，数据库，还有一些辅助的软件。硬件部分就包含内存，磁盘，CPU，网卡等等。另外还有服务器的带宽，使用应用程序的用户量，还有应用程序的响应时间和处理速度等…

貌似看起来要监控的东西有很多，让人无法下手。

其实，问题没有那么复杂，我们可以把上面的N多因素再次划分为两类：可控因素的监控，非可控因素的监控。

所谓，可控因素的监控，就是监控那些我们可以完全控制和改变的因素，例如服务器的软硬件配置，网络出口带宽，应用程序的代码等。

非可控因素就是那些我们无法控制的因素，例如，我们无法预测访问我们站点的用户的带宽是多少，无法知道控制访问我们站点的用户的地理位置，也无法预知访问站点的用户量（有的时候，可能我的站点很不错，一上线，就使得用户量剧增，这样的情况是我们无法控制的）。

做任何的事情都是这样的：极力去改变我们可以改变的，尽可能的去影响我们无法改变的，坦然的接受我们不能改变的。

在调优过程中，我们把监控关注点要放在我们可以改变的地方：可控因素。只要我们发现这些因素里面有性能瓶颈，我们就可以着手改变。至于改变的成本和带来的回报，不仅仅要考虑技术因素，还要考虑商业因素。


对已那些非可控因素监控获得的数据，也可以给我们很多的实质性的指导，例如我们监控知道：很多的用户都是从华中地区访问站点的，此时我们就可以考虑是否要在华中地区放置服务器；再如，我们通过网页的浏览情况，发现有很多的页面的访问量明显的超过其他页面，此时我们就可以把这些用户常常访问的页面和功能进行“有的放矢”的优化…

其实我们可以仔细的回想一下，当我们遇到性能问题的时候，追溯根源都是发生在我们应用程序本身。很多时候，我们编写应用程序的人在写代码的时候，根本没有性能意识，或者说不知道自己写的代码是否高效，最后导致整个应用性能出现问题。所以，在后续的文章中，我们主要会从应用程序方面入手来讲述如何构建高性能的应用。


我们今天暂时说到这里，我先去整理一些工具。我们下一篇文章为大家介绍一些常见的监控与分析工具，让大家心里暂时有个数，我们之后会进一步的详细讲述。