zoukankan      html  css  js  c++  java
  • 【翻译】Netscaler真实表现性能调整

    源地址:https://msandbu.wordpress.com/2014/10/31/netscaler-and-real-performance-tuning/

    作者显然不是以英语为母语的,所以有些地方我看着也比较费劲,但是十分感谢原作者。

    =========翻译内容开始=========

    昨儿我跟Citrix User Group在挪威一起就Netscaler和性能调整开了个会,45分钟的时间里我也没法说太多关于性能调整的,但是我觉得我还是搞了个大差不离。

    下面是会议日程:

    TCP概述,多路TCP,路径最大传输单元

    SSL概述和调整

    自动协商和双工

    Netscaler VPX

    超大帧和LACP

    最后但不是最不重要的移动数据流

    除了移动数据流(Mobilestream)和Netscaler后端feature更紧密结合之外,这篇文章的绝大多数是关于Netscaler优化的核心feature。所以我也会写一篇关于移动数据流的博客。

    首先是TCP属性。默认情况下,1999年之前,TCP属性是没有被修改过的。所以Netscaler默认情况下是遵循兼容性原则而不是高性能,但是理所当然,这里有很多不同的因素掺和在这里头。比如说,你用的是什么样的架构,丢包的情况,带宽,网络抖动,防火墙等等。

    但是主要的事情是,默认的TCP属性是不包含一下几点的:

    *激活Window Scaling (Window Scaling对于发送更多的包是很有用的,因为调整窗口大小意味着我们可以更容易的发更多的数据)

    *激活Selective Acknowledgement(意味着发生丢包之后,我们不用重传所有的数据,比如,如果你想传的包是12345,但是接收者没有收到3,那就只重传3,而不是345)

    *激活Nagle algorithm(先收集更多的数据,直到数据大小达到了MTU上限,然后再发送数据)

    举例来说,ICA架构的协议是不那么正式的,它使用比较小的包(使用很多包头)意味着这不适用于常规TCP属性。

    nstcp_xa_xd_profile(所有我上面提到的所有feature在这个策略里都被激活)但是当然你也有移动用户在不同WLAN之间跳转或者由于天线问题导致丢包。在默认TCP属性里,会使用TCP reno,当检测到丢包时TCP reno将把拥塞窗口减小一半,这对移动用户没什么好处。

    因此Citrix部署了一系列的TCP拥塞处理feature,叫做Westwood+,它将尝试和设备确定当前的带宽,然后根据带宽缩减拥塞窗口。这意味着移动用户可以(在拥塞后)更快的得到更高的传输速度。

    现在10.5版本有个选项是激活MTCP(multiple TCP),那么这是什么意思呢,这是针对你的能支持两种天线的设备(一个是移动数据流量一个是WIFI, 你可以同时使用这两个天线),我们可以对同一个设备同时准备两种TCP连接。这就是个策略设置,很容易搞定。

    问题是你需要有明确的应用被写入来更改MTCP。

    所以进入System –> Profiles –> TCP Profiles (你可以用已有的,也可以创建一个新的)

    勾选Window Scaling

    同时这里也有MTCP(如果你需要的话)SACK还有Nagle。

    当然Nagle也有个坏处就是,它会一直等到数据达到MTU的最大值之后,才会通过有线发送(译者:所以移动用户就别用这feature咯?),这样移动用户就会产生丢包,理论上讲,会有很多数据需要被重传。所以对于SQL来说,也不要用Nagle :)

    比较cool的是,策略针对各个vServer和service使用,取决于服务的种类大家自行取舍用何种策略。

    另外一个事儿是SSL调整, 依然有好几个tips。第一个是quantum size, 默认大小是8KB,意味着Netscaler以8KB为一个单位传送数据到SSL芯片进行加密。我们也可以把这个值调整成16KB,意味着让更多的数据一起被加密。

    所以,对于下载大量文件的时候,16KB的quantum size是比较推荐的。常规的网页(译者:有别于下载页)有很多的小数据在上面,这种情况依然是推荐8KB。

    另外还要说一下自动协商和双工, 这玩意儿每个人都盼着它别出事儿,但是...

    在一些特定的设备上,依然会出问题,所以你经常得在Netscaler上和交换机/路由器/防火墙上手动设置速率啊双工啊啥的

    在VPX上有很多的tips可供调整,但是MPX上就...(译者:作者的意思是在MPX上就特么的呵呵了)

    比如说,在VPX上,它支持多包引擎(multiple packet engine),意味着你可以拥有一个特定的引擎专门运行所有不通的策略、处理加密事务等等。对于一个常规的VPX来说,默认有两个虚拟CPU(一个用于管理,另一个用于包处理),所以如果你有一台VPX3000的话(两个虚拟CPU和2GB内存可能不太够用),如果你在用XenServer或者VMware的话,你可以给它加更多CPU和内存来获取更多的包处理引擎。(注意:Hyper-v不支持这个feature,它的上限就是两个虚拟CPU和2GB内存和两个虚拟网卡,也没法加第三个网卡)

    当然,如果你正在用Hyper-V和VPX的话,确保你用的是最新的驱动并确保你的VMQ(Virtual Machine Queing)

    VMQ的意思是,一个虚拟机在物理网卡上有专门的给VPX使用的队列(queue),如果这个专门的队列挂了,才使用默认的队列,默认的队列平时是和其他虚拟机(译者:估计就是其他平常虚机的意思,比如虚拟的Win7啥的)混在一起的。很多Broadcom的网卡驱动不支持VMQ。

    还有要说的就是LACP(网卡teaming,port channel,802.3ad),能使你聚合并你冗余备份你的多张物理网卡(注意这需要在交换机上做设置,并且只有MPX和SDX支持)

    还有一些10.5的支持巨型帧(Jumbo frames)的新feature(译者:妈呀!啥又是Jumbo frame), 它允许你把MTU设到9000,这样头部变得相对更小,帧的数据空间更大,节省ACK的次数。

    这个也仅仅支持MPX和SDX,因为VPX依赖你的hypervisor是哪家提供的(译者:比如ESXi就是一种hypervisor)

    这个可以在每个接口上设置。但是注意这个需要你的交换机、服务器支持巨型帧,但是注意当进入广域网的时候,这个特性可能就没法正常工作了,因为它可能终结在了运营商的路由器上(绝大多数运营商支持的是默认MTU大小)

    但是注意Netscaler也有Path MTU的feature,这让Netscaler可以提前去探测到它要走的路径里最小的MTU是多少。这个feature使用ICMP来确定下一跳最低MTU。问题在于因为它使用ICMP,但是下一跳有可能是防火墙,因此有可能它也没法正常发挥作用。这个特性主要是为了避免网络中的IP分片。

    就先说这些,仍然在调试更多的Netscaler特性。 :)

    =========翻译内容结束=========

    原作者英语也是各种生硬,有很多地方直接意译了,但是十分感谢这个作者。

  • 相关阅读:
    CopyOnWriteArrayList 读写分离,弱一致性
    Java中定时器Timer致命缺点(附学习方法)
    排队打饭:公平锁和非公平锁(面试)
    母鸡下蛋实例:多线程通信生产者和消费者wait/notify和condition/await/signal条件队列
    volatile,synchronized可见性,有序性,原子性代码证明(基础硬核)
    Synchronized用法原理和锁优化升级过程(面试)
    Java中多线程安全问题实例分析
    iOS 相互引用引起内存泄露问题说明
    iOS app 集成友盟推送问题
    ios即时通讯客户端开发之-mac上基于XMPP的聊天客户端开发环境搭建
  • 原文地址:https://www.cnblogs.com/Vooom/p/4882576.html
Copyright © 2011-2022 走看看