打印本文 打印本文 关闭窗口 关闭窗口
深入研究高性能的 CFMX 应用 II
作者:武汉SEO闵涛  文章来源:敏韬网  点击数987  更新时间:2003/12/4  文章录入:mintao  责任编辑:mintao

版权归属www.7yue.com
独家授权www.blueidea.com转载

监测应用性能

“我怎么才能知道我的站点的运行状态?都说性能很重要,怎么操作才能满足性能呢?”---7yue.com

  站长最喜欢的台词就是黑客帝国中的“Welcome to the real world!”,一句话的背后,包含的数不清的含义。有兴奋,有惊奇,有恐惧,有窃喜。ColdFusionMX的应用在经过长时间的开发后,总是要部署公开的。让众多的最终用户使用自己的ColdFusion应用,才是最终的目的。ColdFusionMX应用在开发阶段经历了数不清的调试和测试,终于发布了。但是真正艰巨的工作才刚刚开始。为什么这么说?ColdFusion应用一旦运行起来,你就不能随意的撤掉已经具备的逻辑,你只能做版本的更新。

  “宁可报错,也别让应用没有响应。”这是我做ColdFusion应用的心得。知道错误,你可以很快的做出反映,修正并且更新。但是程序一旦出现没有任何响应的状况,你就需要花费非常多的心血来重头检查应用的性能和逻辑。

  监测一个ColdFusion应用并不是手到擒来的容易事。首先我们要了解一些能够影响ColdFusion应用的因素。这些因素来自于多方面,但是每一点都很重要。

  硬件是一个从根本上能够影响ColdFusionMX应用性能的因素。普通的硬盘和SCSI的支持RAID5方式的硬盘肯定在读取和存储数据的速度上有着根本的区别。防火墙也是一个因素,想想看,如果防火墙屏蔽掉了一个来自外部的经过1935端口的请求,那么你的FlashCom应用是无法跟外部互相传递视频和音频的。ColdFusion也一样。此外,使用10Base-T和100Base-T的以太网卡对于大型ColdFusion应用的数据吞吐性能上也有所不同。但是这里站长一笔带过,因为他们是有统一的解决方案。有预算,有性能。就这样。

  来自于外部的任何一个请求都会占用系统资源。很多人错误的想法是,ColdFusion的应用只有用户在请求Cfm页面,进行动态数据查询或者其他动态交互操作时才会消耗系统资源。这个观点是错误的。要知道,一个简单的下载浏览一幅Gif图形的http请求,都会消耗系统的资源。虽说这不重要,但是积少成多,这就是我们为什么不做大容量,多图,多动画的首页和做图片下载站点的原因。对于ColdFusionMX而言,性能上已经对于前一个版本有了很大程度上的飞跃。ColdFusion5以前的版本是C++核心,每次外部对于动态cfm模板的请求,服务器端都要使用Run Time(时间运行库方式,即有请求就编译的方式) 的方式进行页面处理,这样,一个ColdFusion应用的服务器,如果有1万个这样的相同请求,ColdFusion5就要在服务器端通过Dll的RunTime方式编译1万次。而ColdFusionMX已经改成了Java Base结构,第一次的请求,服务器会把代码编译成类似于.class的文件存放于服务器端,以后一段时间内相同的请求,服务器都会运行这个编译好的文件,而不是重新编译动态模板。虽说这种方式还存在很多问题,但是对于性能上而言,ColdFusionMX又向前迈出了坚实的一步。

  Ibm Websphere、Bea WebLogic、Sun One、ColdFusionMX都是基于J2ee的中间件服务器。所谓中间件,国外名字叫做Middleware。也就是架构于Web Server之上专门处理动态请求的专有系统。以往Web Server是iis和apache,最擅长干的就是执行外部的http请求返回html静态页面。现在有了中间件服务器(middleware application server) ,我们面临更多的内部操作,比如在ColdFusionMX应用中,我们可能用到数据库查询,可能用到第三方的扩展标签,外部导入的COM和CFX,与外部的Corba应用接口,与Flash和Webservice的集成等等,所以ColdFusionMX应用的性能更是一个重中之重的课题需要研究。

  监测ColdFusionMX应用系统的性能应该从两个方面出发,一个是对于历史系统日志的分析,另外一个就是实时的监控。首先,我们先来研究一下ColdFusionMX系统中对于历史日志的分析。在ColdFusionMX中,从管理端查看Log日志是了解和监测系统性能和运行状况的一个重要手段。在ColdFusion Server里,有下表(表1)的一些Log文件可以时刻反映出ColdFusion应用的运行状况。

表1.ColdFusionMX服务器主要日志文件及作用(参考Macromedia Advanced Engineer Trainning文献)

Application.log 记录ColdFusion服务器的每一个错误 Exception.log 记录服务器端掷出错误的每一个操作 Server.log 记录服务器端的主要错误,从启动以来 Scheduler.log 记录日程的事件。记录每一个事件的初始化和成功结果。前提条件是启动服务器端管理中的Scheduled Tasks。 Customtag.log 记录Custom Tag自定义标签的错误。如果你有自定义标签使用在你服务器中的话。 Car.log 站点存档和恢复的记录 Mail.log 记录由CFMail等功能发送和接收邮件所生成的错误信息 Mailsent.log 记录发送邮件的信息。 Jrun.log 全部存储在C:\CFusionMX\runtime\lib\wsconfig\1下,记录和其他WebServer连接时的错误信息,比如apache和iis。如果是Standalone模式则不会有记录。

  通常我们可以通过以下方式找到这些日志。启动ColdFusion Administrator,选择Debugging & Logging中的Log Files选项,可以看到下图:

ColdFusion MX Log文件图形

  我们在分析Log日志的过程中,应该学会从application.log中找到有用的信息。全都看,非累死不行。在application.log中,第一个要分析的消息就是“Request timed out”。这条信息就意味着ColdFusionMX对于这个信息的原始请求给予了超出正常时间长度的处理。

  另外一个错误是Deadlock,日志里会显示“Deadlock Victim”,就是传说中的死锁。哦,不是传说中,而是实际中。这个死锁意味着你的某些ColdFusion程序的逻辑具有能够让服务器消耗大量资源而无法正常运行的缺陷。发现这些问题后,还是赶快找到对应页面,查询一下原因吧。极有可能一条不经意Select语句就能搞成这样子。

  通过在ColdFusionMX Administrator中可以手动设定日志记录对于页面处理时间的限制。进入CFMX的管理界面,选择Debugging & Logging部分的Logging Settings,进入日志设定部分,我们可以参考下图来修改系统记录页面处理时间的长度。如下图,如果页面的处理时间超过30秒,系统就会记录下来,并存储在server.log文件中。

  除了上面的观察日志外,我们还可以使用WebTrends来进行系统运行状态的检测。使用WebTrends的评估版本,大家可以去www.netiq.com下载。这部分的操作,我就不再赘述。

  通过日志我们看到的是一个系统的历史记录,另外,监控ColdFusion的系统性能,还有一个重要的操作,就是使用Server Probe(服务器监测器) 。Server Probe已经在ColdFusion5的时候就被Macromedia引入CF的管理部分,这个部分被Macromedia保留到了ColdFusionMX中,尤其是实时的Web服务器监测功能。 接下来的部分就是我们如何设定一个实时监测的Server Probe。

  设定一个Server Probe,可以让该Probe在一定的时间间隔内访问你被设定为监控的对象(CFM页面、CFC程序),如果Request被接收,并且正确的从被监控对象返回正确的内容,Probe就把这一次的读取状态结果标识为Success。反之,如果出现404,500之类的错误,Probe就会把状态结果标识为failed。同时,Probe还具备向CF的管理员发送邮件通知和错误原因的邮件,让管理员快速的了解到问题出现了。是不是很酷?嗯,至少我觉得是这样的。下图是我的ColdFusion administrator中没有设定任何Probe时的初始状态,我在原有的状态上做了一些修改。如图:

我们可以试着创建一个简单的Probe。咱们就拿7yue的首页面下手吧。点击上图中“Define New Probe”,进入设定新的Probe界面,如下图:

上图中的Frequency参数我们设定了每天每隔1小时1分钟10秒,服务器的Probe进行一次对7yue首页的cfm页面的侦测,这个时间我们可以随意设定,但是如果我们启用了ColdFusion管理中Server Setting中的Timeout Requests after (seconds)时间,我们必须在这里使用同样的值。User Name和Password则是如果请求的页面有验证保护,则把验证信息输入到这里。Probe Failure是必须要选中的,因为我们7yue的首页中内容有“资源” 两个中文字,所以,通过Request请求回的http页面中应该包含“资源”二字,这才说明7yue的首页是正常显示的。Failure Actions则是选择发信通知还是执行一个应用程序,你可以执行mp3播放器,呵呵。网站一访问不了,就让歌曲通知你吧。最后,我们还可以选择一个系统存在的路径来存放一个针对此Probe生成的log文件,至于log叫什么名字,随意。我起了个probes.log的文件用来存储信息。设定完后的状态如下图:

设定完了以后,我们注意到Probe的状态是Unknown,那么我们来运行一下。看看结果如何,点击Actions栏目中的绿色运行图标(唉~~我的教程太细致了,自己都觉的罗嗦),之后,Probe就会显示OK的状态,如下图:

站点访问量很大,所以首页面的响应时间经常在100ms-150ms左右。同时,我们还能打开log files进行probes.log的信息查看,如下图:

  通过上面的操作,我们可以很轻松的实现对于ColdFusionMX的应用的性能监测。下面,我们还要经常使用一个性能监测的命令。在使用这个命令之前,我们先要打开ColdFusionMX的管理,进入“Debugging Settings”,勾选下图的两个选项即可。

  选择以上2个选项后,我们找到CFusionMX/bin目录下的cfstat.bat文件。我们在命令行的方式下运行这个命令(运行cfstat.bat -h弹出帮助),弹出的结果是:

下表是上述参数的解释说明:

参数 说明 PG/Sec 每秒钟ColdFusion服务器处理多少个.cfm页面。 DB/Sec 每秒钟ColdFusion服务器处理多少个数据库访问请求。 CP/Sec 这个权当一看,因为这个参数已经在ColdFusionMX里不再起作用了。衡量ColdFusion缓存模板的响应数量。 Req Q'ed 每秒钟ColdFusion服务器请求队列中的请求数。 Req Run'g 当前ColdFusion服务器每秒处理active状态的请求数。 Req TO'ed 超时请求的总数 AvgQ Time 一个建议性的参数,大概估计出队列中的请求还需要多长时间的等待。 AvgReq Time 平均每个请求的响应时间。 AvgDB Time 平均每个数据库访问请求的处理时间。 Bytes In/Sec 每秒ColdFusion服务器接收字符数。 Bytes Out/Sec 每秒ColdFusion服务器发送字符数。

通过对实时运行的产品服务器进行cfstat的监控,可以得到有效的性能监测结果,然后,我们可以根据结果中的数据来分析服务器性能。

最后,在cfstat.bat文件的同一路径下,有一个功能更强大的可视化监测文件,名称为“ColdFusionMXServer.pmc”,双击即可打开。打开后,可以进行实时的性能监控。如下图:

好了,关于ColdFusionMX的性能控制,我们就讲这么多。不过,还有很多高级的性能监测手段可以通过组合多种第三方的工具来实现,这个就留给各位去发现了。

下一期我们将讲解如何调整我们的ColdFusionMX和如何开发这样的程序。

打印本文 打印本文 关闭窗口 关闭窗口