对于一个需要长期维护的网站来说,如何让网站长久稳定运行是件很有意义的事情。有些在开发阶段没有暴露的问题很有可能就在运维阶段出现了,这也是很正常的。还有些时候,我们希望不断地优化网站,让网站更快速的响应用户请求,这些事情都发生在开发之后的运维阶段。 与开发阶段不同的,运维阶段不可能让你去调试程序,发现各类问题,我们只能通过各种系统日志来分析网站的运行状况,对于部署在IIS上的网站来说,IIS日志提供了最有价值的信息,我们可以通过它来分析网站的响应情况,来判断网站是否有性能问题,或者存在哪些需要改进的地方。 IIS日志包含了哪些信息我前面说到【IIS日志提供了最有价值的信息】,这些信息有哪些呢?看看这个截图吧: 这里面记录了: 这些信息在分析时有什么用途,我后面再说。先对它有个印象就可以了。 IIS日志的配置默认情况下,IIS会产生日志文件,不过,还是有些参数值得我们关注。IIS的设置界面如下(本文以 IIS 8 的界面为例)。 在IIS管理器中,选择某个网站,双击【日志】图标,请参考下图: 此时(主要部分)界面如下: 在截图中,日志的创建方式是每天产生一个新文件,按日期来生成文件名(这是默认值)。 点击【选择字段】按钮,将出现以下对话框: 注意:【发送的字段数】和【接收的字节数】默认是没有选择的。建议勾选它们。 如何分析IIS日志如果你按照我前面介绍的方法设置了IIS日志参数,那么IIS在处理请求后(的一段时间之后),会生成IIS日志。 比如:我找到了我需要的日志: 这个文件一大堆密密麻麻的字符,现在我该如何分析它呢? 有个叫 Log Parser 的工具就可以专门解析IIS日志,我们可以用它来查看日志中的信息。 'C:\Program Files\Log Parser 2.2\LogParser.exe' -i:IISW3C -o:DATAGRID 'SELECT c-ip,cs-method,s-port,cs-uri-stem,sc-status,sc-win32-status,sc-bytes,cs-bytes,time-taken FROM u_ex130615.log' 现在就可以以表格形式来阅读IIS日志了: 说明:我不推荐用这种方法来分析IIS日志,原因有二点: 推荐的IIS日志分析方法虽然Log Parser支持将解析的IIS日志以表格形式供人阅读,但是有时候我们需要再做一些细致分析时,可能会按不同的方式进行【多次】查询,对于这种需求,如果每次查询都直接运行Log Parser,你会浪费很多时间。幸运的是,Log Parser支持将解析结果以多种格式导出(以下为帮助文档截图): 在此,我建议选择输出格式为 SQL 。 'C:\Program Files\Log Parser 2.2\logparser.exe' 'SELECT * FROM 'D:\Temp\u_ex130615.log' to MyMVC_WebLog' -i:IISW3C -o:SQL -oConnString:'Driver={SQL Server};server=localhost\sqlexpress;database=MyTestDb;Integrated Security=SSPI' -createtable:ON 导入完成后,我们就可以用熟悉的SQLSERVER来做各种查询和统计分析了,例如下面的查询: SELECT cip,csmethod,sport,csuristem,scstatus,scwin32status,scbytes,csbytes,timetaken FROM dbo.MyMVC_WebLog 如果如下: 注意: date, time这二个字段看起来很不舒服,对吧? 1. 在SQLSERVER中增加一列,然后把UTC时间换成本地时区的时间,T-SQL脚本如下: alter table MyMVC_WebLog add RequestTime datetimegoupdate MyMVC_WebLog set RequestTime=dateadd(hh,8,convert(varchar(10),date,120) + ' ' + convert(varchar(13),time,114)) 2. 直接在导出IIS日志时,把时间转换过来,此时要修改命令: 'C:\Program Files\Log Parser 2.2\logparser.exe' 'SELECT TO_LOCALTIME(TO_TIMESTAMP(ADD(TO_STRING(date, 'yyyy-MM-dd '), TO_STRING(time, 'hh:mm:ss')), 'yyyy-MM-dd hh:mm:ss')) AS RequestTime, * FROM 'D:\Temp\u_ex130615.log' to MyMVC_WebLog2' -i:IISW3C -o:SQL -oConnString:'Driver={SQL Server};server=localhost\sqlexpress;database=MyTestDb;Integrated Security=SSPI'-createtable:ON 再看这三列: select RequestTime, date, time from MyMVC_WebLog2 这样处理后,你就可以直接把date, time这二列删除了(你也可以在导出IIS日志时忽略它们,但要明确指出每个字段名)。 IIS日志中的UTC时间问题就说到这里,但愿每个人都懂了~~~~~~~~~~~ IIS日志中的异常记录IIS日志中记录了每个请求的信息,包括正常的响应请求和有异常的请求。 这里所说的【异常】与 .net framework 中的异常没有关系。 本文所说的异常可分为四个部分: 前三类异常可以用下面的查询获得: select scStatus, count(*) AS count, sum(timetaken * 1.0) /1000.0 AS sum_timetaken_secondfrom MyMVC_WebLog with(nolock)group by scStatusorder by 3 desc
declare @recCount bigint;select @recCount = count(*) from MyMVC_WebLog with(nolock)select scWin32Status, count(*) AS count, (count(*) * 100.0 / @recCount) AS [percent] from MyMVC_WebLog with(nolock)where scWin32Status > 0group by scWin32Statusorder by 2 desc
D:\Temp>net helpmsg 64指定的网络名不再可用。
再谈 scwin32status=64记得以前看到 scStatus=200,scwin32status=64 这种情况时很不理解,于是搜索了互联网,各种答案都有,有的甚至说与网络爬虫有关。为了验证各种答案,我做了一个试验。我写一个ashx文件,用它来模拟长时间的网络传输,代码如下: public class Test_IIS_time_taken : IHttpHandler { public void ProcessRequest (HttpContext context) { context.Response.ContentType = 'text/plain'; System.Threading.Thread.Sleep(1000 * 2); context.Response.Write(string.Format('{0}, {1}\r\n', 'Start', DateTime.Now)); context.Response.Flush(); System.Threading.Thread.Sleep(1000 * 2); for( int i = 0; i < 20; i++ ) { context.Response.Write(string.Format('{0}, {1}\r\n', i, DateTime.Now)); context.Response.Flush(); System.Threading.Thread.Sleep(1000 * 1); } context.Response.Write('End'); } 这段代码很简单,我不想做过多的解释,只想说一句:我用Thread.Sleep与Response.Flush这二个方法来模拟一个长时间的持续发送过程。 我们可以在浏览器中看到这样的输出(显示还没有完全结束时我截图了) 我把这个测试做了8次,只有2次是全部显示完成了,其余6次我提前关闭了浏览器窗口。 根据IIS日志并结合我自己的操作可以发现:
寻找性能问题IIS日志中有一列叫:timeTaken,在IIS的界面中显示了它的含义:所有时间。 知道了timeTaken的定义后,我们就可以利用它来分析一些请求的处理时间,即性能分析。 例如,我想查看最慢的20个页面的加载情况,可以这样查询: select top 20 csuristem,scstatus,scwin32status,scbytes,csbytes,timetakenfrom dbo.MyMVC_WebLog with(nolock)where csUriStem like '/Pages/%'order by timeTaken desc 再或者我想再看看最慢的20个AJAX情况的响应情况,可以这样查询: select top 20 csuristem,scstatus,scwin32status,scbytes,csbytes,timetakenfrom dbo.MyMVC_WebLog with(nolock)where csUriStem like '/ajax/%'order by timeTaken desc 总之,寻找性能问题的方法就是:在查询选择timeTaken字段,并且用它做降序排序。 注意:scbytes,csbytes 这二个字段也是值得我们关注的: scbytes,csbytes,不管是哪个数值很大,都会占用网络传输时间,对于用户来说,就需要更长的等待时间。 一下子说了三个字段,在寻找性能问题时,到底该参考哪个呢? 寻找可改进的目标除了可以从IIS日志中发现性能问题,还可以用它来寻找可改进的目标。
如果你希望在开发阶段就能轻易的发现404错误,可以参考我的博客:程序在发布前就应该发现的一些错误
IIS有个【启用内容过期】功能,可用来在输出响应时设置缓存头,减少请求数量。
select top 20 csUriStem, count(*) AS [count], avg(timeTaken) AS avg_timeTaken, max(timeTaken) AS max_timeTakenfrom MyMVC_WebLog with(nolock)where csUriStem like '/Pages/%'group by csUriStemorder by 2 desc 如果发现有大量的重复请求,也需要再仔细分析: 我的博客不修改代码就能优化ASP.NET网站性能的一些方法介绍了一种不用修改代码就能缓存请求的功能,如果需要,可以试试。 程序架构对IIS日志分析过程的影响前面我介绍了一些分析IIS日志的方法,这些方法的使用都离不开查询。绝大多数时候,我们需要在查询中输出URL信息(cs-uri-stem)并依据它们分组来统计,因此,合理的设计URL会给后期的统计带来方便,也能得到更准确的统计结果。一个极端的反例是:采用WebForms默认的开发方式,页面加载以及每个按钮的提交都是同一个URL,你会发现很难统计用户的每个操作花了多少时间。 怎样的URL设计才能满足统计需要呢?
因此,如果你希望利用IIS日志来分析程序性能,那么iframe就不要再使用了。 如果,您认为阅读这篇博客让您有些收获,不妨点击一下右下角的【推荐】按钮。 感谢您的阅读,如果您对我的博客所讲述的内容有兴趣,请继续关注我的后续博客,我是Fish Li 。 |
|