一般而言，slave相对master延迟较大，其根本原因就是slave上的复制线程没办法真正做到并发。简单说，在master上是并发模式(以InnoDB引擎为主)完成事务提交的，而在slave上，复制线程只有一个sql thread用于binlog的apply，所以难怪slave在高并发时会远落后master。

    只读实例是目前RDS用户实现数据读写分离的一种常见架构，用户只需要将业务中的读请求分担到只读节点上，就可以缓解主库查询压力，同时也可以把一些OLAP的分析查询放到另外的只读节点上，减小复杂统计查询对主库的冲击。 由于RDS只读节点采用原生的MySQL Binlog复制技术，那么延迟必然会成为他成立之初就会存在的问题。延迟会导致只读节点与主库的数据出现不一致，进而可能造成业务上逻辑的混乱或者数据不正确；另外只读实例延迟同样也会触发binlog堆积，导致只读实例的空间迅速消耗完，这样会导致只读实例被锁定，锁定之后应用则无法完成读操作。 最近也收到了很多用户关于只读实例延迟的问题反馈，下面将会分析RDS只读实例出现延迟的几种常见场景，希望能够帮助用户理解和处理只读节点的延迟，更好地使用只读节点。

    我们知道，计算机中有很多概念并不容易理解，有些时候一个好的比喻能胜过很多句解释。下面两个是我看到的两个很精彩的比喻，拿出来和大家分享一下：吞吐量和延迟、信号量和互斥锁。

    我们在做网络服务器的时候，通常会很关心网络的带宽和延迟。因为我们的很多协议都是request-reponse协议，延迟决定了最大的QPS，而带宽决定了最大的负荷。 通常我们知道自己的网卡是什么型号，交换机什么型号，主机之间的物理距离是多少，理论上是知道带宽和延迟是多少的。但是现实的情况是，真正的带宽和延迟情况会有很多变数的，比如说网卡驱动，交换机跳数，丢包率，协议栈配置，光实际速度都很大的影响了数值的估算。 所以我们需要找到工具来实际测量下。

    alarm函数是信号方式的延迟，这种方式不直观，这里不说了。 仅通过函数原型中时间参数类型，可以猜测sleep可以精确到秒级，usleep/select可以精确到微妙级，nanosleep和pselect可以精确到纳秒级。 而实际实现中，linux上的nanosleep和alarm相同，都是基于内核时钟机制实现，受linux内核时钟实现的影响，并不能达到纳秒级的精度，man nanosleep也可以看到这个说明，man里给出的精度是：Linux/i386上是10 ms ，Linux/Alpha上是1ms

    我们在做网络服务器的时候，通常会很关心网络的带宽和延迟。因为我们的很多协议都是request-reponse协议，延迟决定了最大的QPS，而带宽决定了最大的负荷。 通常我们知道自己的网卡是什么型号，交换机什么型号，主机之间的物理距离是多少，理论上是知道是知道带宽和延迟是多少的。但是现实的情况是，真正的带宽和延迟情况会有很多变数的，比如说网卡驱动，交换机跳数，丢包率，协议栈配置，光实际速度都很大的影响了数值的估算。 所以我们需要找到工具来实际测量下。 网络测量的工具有很多，netperf什么的都很不错。 我这里推荐了qperf，这是RHEL 6发行版里面自带的，所以使用起来很方便，只要简单的: yum install qperf 就好。

    你有一个队列在Rabbit中。你有一些客户端从该队列消费。如果你完全不配置QoS设置(basic.qos)，这样Rabbit将以网络和客户端容许的尽可能快地速度发送队列中的所有消息到客户端。因为消费者在自己的RAM中缓存所有的消息，他们的内存将暴涨。如果你查询Rabbit，可能出现队列中是空的，但可能有以百万计的未确认的消息，因为它们在客户端，等待客户端应用程序处理。如果您添加了一个新的消费者，没有消息保留在队列中以被发送到新的消费者。消息只是被缓存在现有客户中，并有可能在那很长一段时间，即使有其它变为可用的消费者可以更快处理这些消息。这很不理想。

    Lazy Load是一个用Javascript写得jQuery插件。它可以使一个长网页中，不在当前视图中的图片延迟加载，以提高页面的载入速度。

     latencytop深度了解你的Linux系统的延迟 我们在系统调优或者定位问题的时候，经常会发现多线程程序的效率很低，但是又不知道问题出在哪里，就知道上下文切换很多，但是为什么上下文切换，是谁导致切换，我们就不知道了。