有关CPU占用和缓存的一些见解

上面的例子我想说明一个问题，缓存的方案需要根据应用来选择，静态变量不一定不好，分布式缓存也不一定好。

最后，还有一个有关CPU占用的有趣问题，很多人很怕服务器占用CPU很高，觉得CPU占用一高就有性能问题。其实我想说的是，有的时候CPU占用的高不一定是坏事情。假设有两个网站。A网站它的数据源是数据库，每一个请求（假设是同步请求数据库）都需要1秒来从数据库获取数据，由于IO操作的时间会比CPU处理数据时间长很多，所以这个网站即使很繁忙，WEB服务器的CPU占用还不是很高，用户一个页面打开至少要等1秒，网站管理员看着WEB服务器CPU常年处理20%的情况觉得很满意，但想想这真能说明网站性能高吗？还有一个网站B，它数据都是从内存中读取的，由于内存的操作会比IO操作快很多，CPU处理一个请求的数据只需要20毫秒，由于网站页面速度快，用户满意度和数量比A网站高很多，CPU很忙，常年处于90%的负荷，网站管理员看了觉得很害怕，是不是哪里出现性能问题了，服务器会不会瘫痪。其实，我觉得B网站的管理员应该高兴，因为B网站的用户比A网站高一个数量级，服务器虽然很忙，但页面打开速度很快，CPU得到了充分的利用。

上面的例子我想说明一个问题，只要不是死循环等恶性代码问题的话，CPU如果占用的高不一定就是坏事情。

很多时候事情往往不是像我们想的那样，很多时候好的东西往往也不一定是适合的。希望这三个小例子能给大家一些启发。

最后，想说一下最近使用LINQ的经验。不可否认，如果不分层，在网站中直接使用LINQ TO SQL和LINQ进行数据的存取以及转换，结合匿名类型等特性，至少提高开发效率一倍。有很多人关心LINQ的效率，其实我们应该要区分LINQ还是LINQ TO SQL，是使用LINQ TO SQL进行数据的转换还是使用LINQ进行内存中数据的转换很关键。要知道，尽量从数据库中拿少点东西，尽量少的进行数据库访问，所以说LINQ TO SQL的代码不适合放在循环中，如果要对大量数据操作的话，要先ToList()加载到内存中，然后之后的工作就是LINQ(TO OBJECT)了。如果项目对性能要求高的话，尽量在做好项目之后，多看看SQL监视器，观察一下页面究竟访问了几次数据库，因为程序写的很爽的时候可能会迷糊，导致页面访问N次数据库，这个时候要使用LoadWith来“化解”。