陈力就列 崇论闳议

Referred from: http://blogs.msdn.com/dougste/archive/2006/04/05/568671.aspx

The following are based on problems I see people having every day in production ASP.NET systems.

1. Before you go into production, long before, plan, specify, architect, design, code and test for your application to meet your requirements for performance, scalability, monitorability, diagnosability. If your requirements are anything like my requirements they equal a quiet life and long coffee breaks.  As a starting point the patterns and practices guide Improving .NET Application Performance and Scalability provides an excellent starting point.

2. Ensure that the debug="false" on the <compilation> element in the web.config file of each and every ASP.NET application on the server. The default during development is "true" and it is a common mistake to allow this development time setting to find its way onto production servers during deployment. You don't need it set to true in production and it often leads to memory overhead and inefficiencies.

3. Wherever possible strong name and install to the global assembly cache (GAC) any assemblies that are used by more than one ASP.NET application. This will reduce memory consumption. In ASP.NET 1.1, do not deploy strong named assemblies to the BIN directory (i.e. if they are strong named make sure you DO put them in the GAC). Note that if assemblies are going in the GAC they need to be designed to operate in the shared AppDomain and you have to trust whoever wrote them.

4. If your ASP.NET application calls web services be aware that the default configuration of HttpWebRequest allows only 2 concurrent outgoing HTTP connections to a particular endpoint at a time (to comply with the specification). For example if you have 25 concurrent ASP.NET request going on, all making web service calls to the same web service, only two will actually be doing anything. Misconfiguration of this causes major scalability headaches. Start by reading this article.

5. Be careful using things that generate dynamic assemblies behind the scenes. These can include RegEx, XslTransform and XmlSerializer. For example if you create XmlSerializers using contructors that are documented as "for internal use only" you will get into trouble because the dynamic assemblies that are created do not get cached and re-used. In a production system this can lead to major memory leaks and bring a server down. For RegEx and XslTransform, try to reuse them wherever you can.

6. In IIS6 make good use of application pools and configure their performance and health monitoring capabilities sensibly. You don't have to have all your applications configured to run in the DefaultAppPool. Putting applications into different application pools allows you to do things like isolate an application that has particular memory usage or stability issues, or allow one particular application to use a version of the .NET runtime that your other applications are not currently compatible with.  You should also pay attention to the configuration of application pools. By default application pools are configured to recycle after 1740 minutes. This is 29 hours. This means that your application pool might recycle in the middle of the night one day and then in the middle of your peak online shopping time the next day. As a better alternative, configure the application pool to recycle at a specific (quiet) time of day.

7. Keep an eye on your event logs. This is where important and critical messages get logged. There is a good list available for ASP.NET. Note that some of the most importand ones to watch out for (like 1000 and 1003) are only applicable if you are using IIS5 or using IIS6 in IIS5.0 compatability mode. If you are using IIS6 in native mode then the management of the process hosting ASP.NET code is taken over by IIS6 itself and the aspnet_wp.exe worker process is no longer used. In that case IIS6 will log events relating to application pool recycles and terminations. It is important to note however that IIS does not log all such events by default. This article explains how to configure what events are logged. The default value for the metabase value LogEventOnRecycle is 137 which means it only logs an event for recycles due to defined memory thresholds being reached (by default there are none) or due to an elapsed time having passed (by default 1740 minutes). I always recommend setting this to 255 for all application pools. 

The other thing that sometimes happens when you start looking at event logs is that you discover that your application developers have been over enthusiastic in spewing out events that or often not very interesting. It is important to log events when things go wrong by be aware that you can sometimes flood the event log thus masking important messages. I would recommend creating your own event log when you install the application and log your events to that. Also consider giving your application configurable "levels" of event log. So by default you would only log events when something really bad happens but you build in the facility to increase the verbosity and detail of the events when you are investigating a specific issue.  There are a number of predefined logging and tracing facilities around like the logging application block and log4net.

8. Monitor performance from time to time, especially in the early weeks after "go live". Things may have gone great during all your performance and scalability testing (you did do performance and scalability testing right?) but the real world is always different. A very useful article to get started is ASP.NET Performance Monitoring, and When to Alert Administrators. It is amazing how often it is discovered after a system has gone live that it is using huge amounts of memory or throwing a ridiculous number of exceptions.

9. Deploy updates to your applications at an appropriate time of day. It makes sense deploy updates to your site at a time when traffic is low, like 3am. Of course many web sites (especially internet facing ones) are live 24 hours per day but ever site has its quiet times. I also recommend stopping the application pool (or IIS in the case of IIS5), deploying all your updates and restarting the application pool/IIS. Although ASP.NET shadow copying allows the "hot" deployment of assembly and page updates these will generally trigger an application restart within the worker process or application pool. That's all very well if your application has a normal memory footprint of 20Mb and is the only application on the server but what if it uses 300Mb and the other applications use 700Mb. In "steady state" that is fine but if the 300Mb application goes through a restart this could temporarily push the overall memory usage in the process beyond a critical level.

在C#的WinForm程序中，有的时候需要判定关闭请求从哪里发出来的。比如是用户点击了右上角的“关闭”按钮，还是调用了WinForm.Close()方法。最典型的是要知道点击右上角的“关闭”按钮发出的事件。下面这个方法可以判断这点：

protected override void WndProc(ref Message msg)
{ 
        const int WM_SYSCOMMAND = 0x0112; 
        const int SC_CLOSE = 0xF060;  
  
         if (msg.Msg == WM_SYSCOMMAND && ((int)msg.WParam == SC_CLOSE)) 
         { 
                 // 点击winform右上关闭按钮 
                 // 加入想要的逻辑处理

                 return;
         } 
         base.WndProc(ref msg); 
}

★活动目的
为感谢新老朋友对美名腾的支持和喜爱，同时让更多朋友享受美名腾的优质服务。从即日起，免费注册成为美名腾会员，并邀请您的亲朋好友前来使用美名腾相关产品，就可以获得积分，赢取抽奖机会，丰厚数码奖品等您来拿。先到先得，奖品送完为止，赶快行动吧！

★奖项设置及奖品数量
一等奖2名：价值约100元的MP3时尚音乐播放器一台（或等值的100腾讯Q币）；
二等奖4名：价值约50元的精美U盘一只（或等值的50腾讯Q币）；
三等奖10名：价值约20元的超酷耳机一只（或等值的20腾讯Q币）；
四等奖20名：奖励10腾讯Q币（价值约10元）。
（注：一、二、三等奖中奖后，实物奖品和等值的腾讯Q币只能任选一样！）

★参与方式
用户可以免费注册成为美名腾会员（点击这里注册：http://www.meimingteng.com/Account/Register.aspx），一旦注册成功即可免费获赠10积分（相当于充值10元人民币获得的等值积分数目）。同时，你也可以邀请你的亲朋好友前来免费使用美名腾相关的产品和服务。如果你所有邀请的朋友也注册成为美名腾会员，则给予邀请者相应的奖励积分。每成功邀请一个会员将获得5个积分。邀请的朋友越多，你所获取的奖励积分就越多。当你的积分达到50分的时候（只需要邀请8个朋友就够了哦），就可以参与抽奖，有机会赢取MP3，U盘，耳机，Q币等精美数码奖品。同步的，每抽奖一次我们会相应的从你帐户上扣除50积分。你的积分越多，获得的抽奖机会也就越多，中奖的机会同步的也增大了很多。（关于注册和成功邀请朋友请参见友情提示）

本次活动本着公平参与，公平抽奖的原则，为了杜绝各种作弊行为（详见“抽奖注意事项”第一条），所有中奖者中奖后，需由美名腾工作人员进行审核。如无作弊行为，我们会尽快把奖品寄出（邮寄费由美名腾提供）。如果确认中奖者有作弊情况发生，则所中奖品将被无条件驳回，奖品将重新放入奖池中。所有奖品抽完为止，先到先得。（为确保公正性，美名腾员工及家属不得参加此次抽奖活动。）

友情提示：
注册成为美名腾会员方法：打开美名腾网站任何一张页面，点击页面右上方导航条里面的“注册”，在打开的注册页面中根据提示填写相应的信息即可。整个注册大约需要10秒钟即可完成，非常简单。注意：为了在你中奖后我们能尽快寄出奖品，请在中奖后准确填写邮寄地址、收件人、邮政编码等信息。

邀请好友方法：登录美名腾，在页面右上方的导航条里面选择“我的账户”，在我的账户页面里面选择“邀请好友”页面，复制里面的邀请链接或者邀请代码到你的个人QQ，MSN签名，或者发到你的博客，论坛，社会关系网络，也可以以邮件的方式发送给你的朋友。

查看积分和抽奖方法：登录美名腾，在页面右上方的导航条选择“我的账户”，在我的账户页面里面选择“积分记录”，在这里就可以看到你目前的积分数以及可以参与的抽奖次数。抽奖所用的幸运大转轮也位于这个页面上，如果你的积分足够，就可以参与抽奖啦！

更多活动详情，请点击美名腾智能起名网::积分抽奖活动详情 

相关链接：美名腾智能起名网

　　本人以前是Google的忠实使用者，但我也不排斥百度，甚至常见的搜索都用百度。理由很简单，百度搜索一些生活中的小问题，还是很好用的，而且速度快，可以使用其页面缓存功能。至于Google，一般是搜索英文内容，或者百度实在搜索不到满意内容的时候才会用它。Google的技术不容置疑，Google的产品当然也是引领着当今互联网的潮流。本人曾经研究过搜索引擎的相关技术，深知其中的水深水浅。当然，百度也不是吃素的，技术那也是相当了得的。Google在全世界范围来说，是绝对老大。但这个绝对老大在中国却只能甘当万年老二？？？其实我是一直坚信Google能在某天超过百度，在中国也做一回老大。但或许这只是痴人说梦而已，Google在中国远没有这么强势。个人感觉，中国只是Google全球战略的一部分，而对百度而言，中国就是全部。从这两者对中国市场的态度来看，也能部分理解Google为什么在中国这么疲软。再者，据朋友说，百度在中国的渠道做得很好，好到已经让Google的人开始有些绝望了。可能有的人会说百度不太地道，但这就是事实。

　　好了，扯得有点远了，还是言归正传吧，说说我发现的问题。从我们网站上线也快有一个月了，其间通过自己和朋友写Blog的形式，在网上也存在不少介绍我们网站的文章和链接。由于推广的需要和本身对此比较感兴趣，我一直在观察各大搜索引擎索引我们网站的能力。这里主要考察索引的速度，精度，以及索引的网页数目。对比发现，百度的索引速度是最快的，上线不到一周就能检索到我们网站的首页，其次是雅虎，搜狗，有道。至于Google和Live Search到现在也几乎无法搜索到。我仔细分析了网站日志，发现Baidubot是最勤快的，每天都是光顾网站数次。Sogou也比较勤快。一开始，我怎么也没看到标识为Googlebot的爬虫，我再仔细看了我的robots.txt文件，上面明明写着欢迎各大爬虫光临的啊。突然，有一天看到有一个表示为Mozilla 5.0的bot在短时间内发送了大量的请求过来，我一查IP，说是“北京飞翔人信息技术有限公司”，好像是赶集网的IP。到网上一查，很多人说这就是Google的爬虫！！狂汗了一把，Google的爬虫为什么不标识为Googlebot呢？而且，作为一个爬虫程序，为什么会在这么段的时间里发送了大量的请求呢？这种高强度的爬取页面，肯定会给网站带来一定的压力。就在昨天，我看到了Googlebot的身影，明确标识为Googlebot的一个爬虫。我相信，这就是Google的爬虫。这里我有一个猜想，是不是对于刚上线的新网站，Google会用一个二三流的爬虫过来，能爬几个网页是几个网页。等你网站存在一段时间了，再用他们正式的爬虫过来。我估计，这也是Google索引新网站不如百度的原因吧。不知道，Google为什么会对这样的新网站区别对待。至于其他几个搜索引擎，像雅虎，搜狗，有道，Live search什么的，索引的频率也不是很高。感觉还是百度对新站，至少是新的中文站点敏捷一些。当然，这只是根据我的经验得出的结论，不知道其他站长是否有类似的经历，不妨大家一起来分享一下。不妨大家探讨一下如何能让Google快速索引你的新网站？

其他文章导读：