后续应用层数据交互过程中，我们可以看出域控制器的服务端应答时间也非常小(1ms左右)。
整个会话在开始后约996ms后事务处理完成，其后有约20s的空闲时间，会话应用层关闭。如下图：
图 7
从这个会话交互过程我们可以判断，该会话虽然持续20多秒时间，但在1秒之内已经完成了登录过程必须的数据交互。
通过对其他域登录所触发的会话分析，我们发现这些会话均在1秒之内完成了有效数据交互，可以确定整个域身份验证过程从15：58：34开始，到15：58：36已经验证完成。因此Citrix平台客户端登录的身份验证过程并不会直接导致用户感受缓慢。
04故障应用管理平台应用会话响应时间分析
Citrix虚拟化平台与10.161.8.41应用服务器之间建立的两个TCP会话，三次握手延时和服务器应用层响应时间也很短，如下图。
图 8
但是从会话整体延时统计中，我们可以看出整个会话的主要时间占用源自“客户端空闲时间”，如下图。
图 9
“客户端空闲时间”是指客户端与服务端一次应用层交互完成后，到下一次发起应用层请求的间隔时间，在故障应用平台客户端打开的过程中并没有额外需要人工干预的过程，因此出现大量“客户端空闲时间”说明客户端系统(10.230.3.112)或客户端程序处理出现问题，导致不能及时向服务端发送下一次应用层请求。
从会话交易时序图中，我们可以看到两个会话均有一次明显的客户端空闲，如下图。
图 10
图 11
可以判断，这些客户端空闲是使用者感受缓慢的直接原因，很可能是这段时间客户端程序处理过于缓慢，导致很长一段时间没有发送应用层请求。
在其他时段，我们随机选择了一些10.230.3.112与10.161.8.41的TCP会话，均发现了相同的客户端空闲，如下图。
图 12
并且我们发现在较长的客户端空闲后，10.230.3.112发起的主要是两个应用层请求：
select right_id， right_type， module_id， module_name， right_name， right_value from tco_role_rights where role_id =… and right_type=….
select userid， config_class_name， config_version， config from tap_wf_userRelatedConfigs where userid=… and config_class_name=… and config_version=…
至此，我们推断故障应用平台的客户端程序，在发送上述两个查询之前的处理过程过于缓慢，建议系统研发人员对程序处理过程进行深入分析。
05Citrix平台响应时间分析
用户终端与Citrix平台(10.230.3.112)之间的会话，三次握手和应用层响应时间也非常快，如下图。
图 13
在故障应用管理平台会话的客户端空闲时间内，10.230.3.112与10.230.3.125之间只有少量的数据交互，在15：58：21.336时刻可以看到10.230.3.112向10.230.3.125发送了很多大数据包，如下图。
图 14
而这一时刻与10.230.3.112在长时间等待后向10.161.8.41发送新的应用层请求的时间点吻合(滞后3ms)，这说明Citrix平台在应用软件处理完成后能够很快的将处理后的图像数据发送给用户终端。
可以判断Citrix平台并没有对用户访问造成明显的延时(以上延时不包括Citrix客户端程序处理图像数据到最终显示出来的时间)。
本文为授权转载文章，任何人未经原授权方同意，不得复制、转载、摘编等任何方式进行使用，e-works不承担由此而产生的任何法律责任! 如有异议请及时告之，以便进行及时处理。联系方式：editor@e-works.net.cn tel：027-87592219/20/21。
需求中心
AI助手
联系我们
返回顶部