陷阱还是馅饼？TMG升级经验总结(图)

　　这个警报并不复杂，意思是SCOM服务器三分钟内随机统计了5个客户机向TMG服务器发起一个Web请求后所需要的平均响应时间，TMG服务器发现客户机平均需要经过800豪秒才能从TMG服务器收到回应。这就有些不对了，SCOM服务器认为这个平均值应该在300毫秒以下。考虑到客户机发起请求后，如果请求的内容在TMG的Web缓存中，那响应速度应该在10毫秒以内。因此，看到这个警报，我就考虑是否TMG的缓存性能出现了问题。可是，我很快就发现一个难以自圆其说的现象。SCOM服务器发起这个警报的时间，基本都是在夜间或双休日，工作时间内反而没有警报。那就不对了， TMG服务器应该在工作时段负载重啊，怎么反而在工作时段没有这个警报呢?没辙了，再去微软开个CASE吧。微软工程师的水平还是挺高的，查了一番资料后给了我一个挺好的解释：是这样的，如果用户访问的内容在TMG的缓存中，那TMG的响应速度是很快的;如果用户访问的内容不在TMG的缓存中，例如用户下载文件，或者用户使用视频点播，这种情况下TMG就得先从互联网服务器下载数据，然后才能响应用户，这样响应时间就会很长，需要上千甚至上万毫秒都有可能。在工作时间内，很多用户提交的Web请求都可以在TMG缓存中得到响应，因此缓存的利用率高。平均一下，每个用户提交Web请求所需要的平均响应时间就会非常短，SCOM就不容易报警。非工作时间呢，使用TMG服务器的用户少了，TMG的Web缓存利用率就低了，用户的Web请求就不容易从TMG缓存中获得响应(你可以想象一下，非工作时间用户访问的是神马内容)，因此统计出来的平均响应时间就长，这时就有可能触发SCOM警告了。

　　听了微软的解释，我觉得豁然开朗。哦，原来TMG服务器的缓存性能没问题，这时好事，值得高兴啊。但是，但是，仔细一想就不对了，TMG服务器没问题，你SCOM报什么警啊!存心骚扰是不是?我向微软的工程师咨询：既然如此，SCOM的这个警报到底有什么意义呢?这回轮到微软的工程师张口结舌了，只能推说要和产品组反映这个问题，然后给我答复。过了几天，微软工程师来电话了：经过和产品组确认，确定这又是一个产品Bug!解决方法是等待产品组的Hotfix，Hotfix没出来之前建议先把SCOM的这个警报禁用，免得收到无意义的警报。既然是Bug，那这个CASE还是免费的…

（编辑：云计算网_泰州站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!