编者按:某能源集团通过HP OpenView进行系统管理，然而在实际应用中，当登陆到关键应用服务器进行多种操作时，有明显的响应过慢现象。这该怎么办？

　　问题：明显的响应过慢现象
　　问题分析：流量监测无法找到问题原因
　　深入分析：主要原因是应用层数据传输控制所致
　　问题解决：修改应用层控制，减少传送次数

　　【IT168 专稿】国内某综合性能源集团，位于世界同行业前10位之列。公司内部采用各种媒体视窗实时展示实用信息，即公司内采用Portal方式，通过各种大屏幕显示各种关键业务信息、网络状况、行业动态及重要指示等等。

　　问题：明显的响应过慢现象

　　在整体应用架构中，Portal应用服务器通过HP OpenView多种组建数据库收集信息，如OVO、NNM、MOM等，存储到2台Oracle数据库服务器，同时将收集到的信息通过各个大屏幕显示
　　客户遇到的问题是管理Portal的MO应用服务器在某些时候显示信息延时较大，尤其登陆到应用服务器进行多种操作时，有明显的响应过慢现象。

　　之前采取的解决措施：
　　用户怀疑应用服务器性能低下，于是花费过千万RMB采购一台IBM 59系列服务器代替以前的服务器，但问题仍旧没有解决

　　系统构架：

　　问题分析：流量监测无法找到问题原因

　　通过监测相关流量，获得如下信息：

　　总流量变化趋势：
　　通过分析，发现在某些时段有流量高峰出现，产生流量高峰的主机主要为应用服务器和OVO数据库服务器：

　　单向流量监测---流入
　　有较大流量在同一时间段流入一台Oracle数据库

　　单向流量监测---流出
　　而流量发送也比较明显，主要是应用服务器发送

　　流量监测分析结论：
　　通过以上图象分析，出现流量高峰的主要原因是应用服务器和一台Oracle数据服务器进行数据传输，但整体流量并不大，最高时段也是20,000Kb左右，这对内网来说，造成应用性能低下的可能性不大。
　　可以看出，单纯从流量监测无法足以证明问题的原因，只能进行下一步，流量数据包级分析，也许能够找到问题答案。
 

　　深入分析：主要原因是应用层数据传输控制所致

　　察看捕获流量信息，过滤出应用服务器与Oracle数据库服务器（DB1）之间的流量进行分析

　　数据包特征分析：

　　通过分析，2台设备之间的流量数据包较小，几乎都是小于100Bytes的小包
　　交互次数非常之多，放大某时间段内容深入观察，发现较为严重的问题，发送方与接收方数据包传输呈竖直平行线，平行线意味这无论数据传输的任何一方，都要等到前一个数据包到达后再发送第二个数据包

　　 
　　这里插入一点基础常识：
　　想要提高应用效率，发送方应根据接收方宣告的窗口大小和网络拥塞窗口大小尽量多发送数据，而接收方确认是否收到数据包以保证数据传输的完整性，理想的或常见的数据传输型应用数据包传输方式应该如下：

　　网络连接特征分析：
　　任意过滤出一个连接，展开察看，得出如下信息：

　　一个连接由十余万个Turns组成：
　　       （Turns概念，俗称交互，即一对数据包组成：请求+回应）

　　应用层数据包很小：

　　延时分析：

　　从延时统计可以得出，在长达17S的数据传输过程中，应用服务器和数据库服务器分别占用了整体时间的42%和56.4%,而带宽延时很小 
　　通过前面的相关信息，得出这样的延时数值可以说很正常，我们来这样一个算法：
　　无论是应用服务器端还是数据库服务器段，每个请求处理延时即使是0.00005秒，十几万的交互处理加起来也是一个较大的时间延时，当然，应用服务器还有处理其他应用
 

　　问题解决：修改应用层控制，减少传送次数

　　问题原因及处理建议：
　　通过以上分析我们得出
　　产生问题：主要原因是应用层数据传输控制所致，这是很典型的数据回复型确认
　　问题处理建议：修改应用层控制，减少传送次数，增大发送数据包，以及改善确认方式

　　分析总结：
　　应用性能问题在日常生活中无处不在，而问题的定位和原因查找，传统的管理方式已无法胜任或者会导致解决问题的效率低下，通过网络分析技术可以帮助用户快速、准确定位问题产生的原因，给出科学、合理的解决方案