https://www.zhihu.com/question/23185359/answer/936467060
作者：panda
链接：https://www.zhihu.com/question/23185359/answer/936467060
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。
虽然是一个老问题，但这确实是一个很有意思的问题。凑个热闹，根据自己的经验来谈谈。（友情提示，重头戏在本文结尾处）
Scott Meyers曾经说过这么一句话“if you are not at all interested in performance, shouldn't you be in the Python room down the hall”。系统性能对交易系统的重要性不言而喻，而低时延对高频系统来说，就是非常重要的系统性能之一，哪怕说是最重要的也不为过。
那么在回答怎么才能做到低时延的时候，我们首先需要知道，对于一个高频交易系统来说，latency方面最大的bottleneck依次是哪些。而要知道latency的bottleneck，你又需要一个合理的测量时延的测试环境，这方面陈硕的回答已经很赞，我就不赘述了。
很有意思的是，通常取得最好效果提升的地方却是与编程语言无关的。比如，网络时延一般就是延迟方面最大的bottleneck之一。所以为了降低网络时延，我们需要colo，需要物理上与交易所的撮合机越近越好，需要高的带宽和最快的nic卡及其模式（比如选择合适的openload模式）。更高阶的，可以考虑使用fpga，或者是定制的nic卡。
与上一条息息相关的，其实就是在数据，比如市场信息，进入cpu之前（当然那种fpga进，fpga出的特殊解决方案除外），尽量减少数据拷贝以及context switches。比如，大家经常提到的Solarflare的nic卡就是通过interrupt kernel来达到kernel bypassing的效果。
以上这些说到底是为了解决更快的I/O，但这还不够，还进入讨论具体程序之前，需要一系列的server tunning。这里我只提几个比较显而易见的：1. disable hyperthreading，2. turn on over clocking, 3. disable Nagle's algorithm，4. set cpu affinity and isolation。
代码实现方面，大概可以参考以下几点（但不限于此）：
- 对于低时延系统，能用单线程解决问题，就千万不要多线程。
2. 一定要有一个hot-path的概念，在它范围内的代码需要仔细优化。当然，hot-path对于core dev和strategy dev的概念可能是有些许不同的。
3. 尽量让run-time的数据处理变得简单。在C++里面, 那就是template metaprogramming。能用CRTP的地方就别用dynamic polymorphism。能用expression templates来帮助计算的，就可以考虑使用它。
4. 尽量避免run-time的memory allocation。可以考虑重复使用同类的object，或者是memory pool，这样可以避免overhead，也可以减少memory fragmentation。
5. 要了解自己待处理的数据，这样在一定条件下可以允许undefined behavior的存在。比如，vector[] vs vector.at()。对于一个sub-microsecond级别的系统，safety check有时候都会expensive。
6. 利用好cache。基本的规则大概就是： 能在cache里面存下data和instructions，就不用access main memory，能在registers里面存下，就不要access cache。尽量使用contiguous blocks of memory，这也是为什么Bjarne Stroustrup本人也会推荐大家优先考虑使用vector。至于怎么写cache friendly的代码，可以参考这个： http://cppatomic.blogspot.com/2018/02/cache-friendly-code.html。
7. 注意好struct padding。也要留意在多线程情况下会出现的false sharing情况。
8. 避免不必要的branch和table lookup。使用virtual functions和大量叠加的if语句，都有可能增加cache misses和pipeline clearances的可能性。
9. 用好编译器提供的builtins，像是__expected，__prefetch之类。
10. 得了解编译器和连接器在做什么。比如，最好不要简单的假设-O2就可以帮你解决全部问题。有时候，O2/O3的优化，因为各种原因，反而会让代码变慢。比如： GCC fails to optimize aligned std::array like C array。
11. 大多数情况下，大家还是会首选用STL里面的container，但是还是需要谨慎，比如std::undered_map的性能对于低时延系统就不够用。
以上这些，虽然写下来看着感觉都不难，但都需要一定程度的经验积累，而如果有乐于分享经验的朋友或者同事，那可能就会事半功倍了，所谓他山之石可以攻玉！好了，重头戏来了！让我们来看看著名高频公司optiver的senior dev在cppcon17上都和我们分享了什么： https://www.youtube.com/watch?v=NH1Tta7purM。
其实有这样的同事真的是好事，比如DRW前员工Matt Godbolt就非常喜欢分享，他也有自己的channel： https://www.youtube.com/watch?v=fV6qYho-XVs。
细节决定成败，而很多细节知识又大多来源于经验和教训，大概这就是senior的意义吧？
作者：陈硕
链接：https://www.zhihu.com/question/23185359/answer/23853729
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。
谢邀。只搞过 sell side，没搞过 buy side，只能算“实时交易”，算不上“高频交易”。工作以来一直在跟延迟做斗争，勉强可以说上几句。
要控制和降低延迟，首先要能准确测量延迟，因此需要比较准的钟，每个机房配几个带GPS和/或原子钟primary standard的NTP服务器是少不了的。而且就算用了NTP，同一机房两台机器的时间也会有毫秒级的差异，计算延迟的时候，两台机器的时间戳不能直接相减，因为不在同一时钟域。解决办法是设法补偿这个时差。另外，不仅要测量平均延迟，更重要的是要测量并控制长尾延迟，即99百分位数或99.9百分位数的延迟，就算是sell side，系统偶尔慢一下被speculator利用了也是要亏钱的。
普通的C++服务程序，内部延迟（从进程收到消息到进程发出消息）做到几百微秒（即亚毫秒级）是不需要特殊的努力的。没什么忌讳，该怎么写就怎么写，不犯低级错误就行。我很纳闷国内流传的写 C++ 服务程序时的那些“讲究”是怎么来的（而且还不是 latency critical 的服务程序）。如果瓶颈在CPU，那么最有效的优化方式是“强度消减”，即不在于怎么做得快，而在于怎么做得少。哪些可以不用做，哪些可以不提前做，哪些做一次就可以缓存起来用一阵子，这些都是值得考虑的。
网络延迟分传输延迟和惯性延迟，通常局域网内以后者为主，广域网以前者为主。前者是传送1字节消息的基本延迟，大致跟距离成正比，千兆局域网单程是近百微秒，伦敦到纽约是几十毫秒。这个延迟受物理定律限制，优化办法是买更好的网络设备和租更短的线路（或者想办法把光速调大，据说 Jeff Dean 干过）。惯性延迟跟消息大小成正比，跟网络带宽成反比，千兆网TCP有效带宽按115MB/s估算，那么发送1150字节的消息从第1个字节离开本机网卡到第1150个字节离开本机网卡至少需要 10us，这是无法降低的，因此必要的话可以减小消息长度。举例来说，要发10k的消息，先花20us CPU时间，压缩到3k，接收端再花10us解压缩，一共“60us+传输延迟”，这比直接发送10k消息花“100us+传输延迟”要快一点点。（广域网是否也适用这个办法取决于带宽和延迟的大小，不难估算的。）
延迟和吞吐量是矛盾的，通常吞吐量上去了延迟也会跟着飚上去，因此控制负载是控制延迟的重要手段。延迟跟吞吐量的关系通常是个U型曲线，吞吐量接近0的时候延迟反而比较高，因为系统比较“冷”；吞吐量上去一些，平均延迟会降到正常水平，这时系统是“温”的；吞吐量再上去一些，延迟缓慢上升，系统是“热”的；吞吐量过了某个临界点，延迟开始飙升，系统是“烫”的，还可能“冒烟”。因此要做的是把吞吐量控制在“温”和“热”的范围，不要“烫”，也不要太冷。系统启动之后要“预热”。
延迟和资源使用率是矛盾的，做高吞吐的服务程序，恨不得把CPU和IO都跑满，资源都用完。而低延迟的服务程序的资源占用率通常低得可怜，让人认为闲着没干什么事，可以再“加码”，要抵住这种压力。就算系统到了前面说的“发烫”的程度，其资源使用率也远没有到 100%。实际上平时资源使用率低是为了准备应付突发请求，请求或消息一来就可以立刻得到处理，尽量少排队，“排队”就意味着等待，等待就意味着长延迟。消除等待是最直接有效的降低延迟的办法，靠的就是富裕的容量。有时候队列的长度也可以作为系统的性能指标，而不仅仅是CPU使用率和网络带宽使用率。另外，队列也可能是隐式的，比如操作系统和网络设备的网络输入输出 buffer 也算是队列。
延迟和可靠传输也是矛盾的，TCP做到可靠传输的办法是超时重传，一旦发生重传，几百毫秒的延迟就搭进去了，因此保持网络随时畅通，避免拥塞也是控制延迟的必要手段。要注意不要让batch job抢serving job的带宽，比方说把服务器上的日志文件拷到备份存储，这件事不要在繁忙交易时段做。QoS也是办法；或者布两套网，每台机器两个网口，两个IP。
最后，设法保证关键服务进程的资源充裕，避免侵占（主要是CPU和网络带宽）。比如把服务器的日志文件拷到别的机器会占用网络带宽，一个办法是慢速拷贝，写个程序，故意降低拷贝速度，每50毫秒拷贝50kB，这样用时间换带宽。还可以先压缩再拷贝，比如gzip压缩100MB的服务器日志文件需要1秒，在生产服务器上会短期占满1个core的CPU资源，可能造成延迟波动。可以考虑写个慢速压缩的程序，每100毫秒压缩100kB，花一分半钟压缩完100MB数据，分散了CPU资源使用，减少对延迟的影响。千万不要为了加快压缩速度，采用多线程并发的办法，这就喧宾夺主了。
作者：闵康
链接：https://www.zhihu.com/question/23185359/answer/137034841
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。
我们的程序的响应时间是10us（从收到行情到发出报单的响应时间），但是ping期货公司的交易前置机需要大约30us【这个数值会变化，见注释4】，所以网络延时占据了大量时间。
我所有的性能测试都是在一台DELL r630机器上运行的，这台机器有2个NUMA结点，CPU型号是E5 2643 v4（3.4GHz 6核）。所有的测试都是用rdtsc指令来测量时间，Intel官网上有一篇pdf文档[Gabriele Paoloni, 2010]，讲述了如何精准地测量时间（要用cpuid来同步）。我自己做的性能测试的结果会写成“100(sd20)ns”的形式，代表平均值是100ns，标准差是20ns。我在算均值和标准差的时候会去掉最大的0.1%的数据再算，因为那些数据似乎并不是程序延时，而是cpu被调度执行别的任务了【原因见注释3】。有些性能测试在网上有现成的测试结果，我就没自己测，直接拿来用了，但是以后我会重新在我的机器上测一遍。
一些我们比较注意的点：
1.限制动态分配内存
相关的知识背景：glibc默认的malloc背后有复杂的算法，当堆空间不足时会调用sbrk()，当分配内存很大时会调用mmap()，这些都是系统调用，似乎会比较慢，而且新分配的内存被first touch时也要过很久才能准备好。
可取的做法：尽量使用vector或者array（初始化时分配足够的空间，之后每次使用都从里面取出来用）。尽量使用内存池。如果需要二叉树或者哈希表，尽量使用侵入式容器（boost::intrusive）。
性能测试：我测试的分配尺寸有64和8128两种。首先，我测试了glibc malloc的性能，分配64字节耗时98(sd247)ns，分配8128字节需要耗时1485(sd471)ns。其次，我写了一个多进程安全的内存池，分配64字节需要29(sd15)ns，分配8128字节需要22(sd12)ns。【内存池的细节见注释6】。最后，我单独测试了sbrk()和first touch的性能，但是数据不记得了。
2.使用轮询，尽量避免阻塞
相关的知识背景：上下文切换是非常耗时的，其中固定的消耗包括（cpu流水线被冲掉、各种寄存器需要被保存和恢复、内核中的调度算法要被执行），此外，缓存很有可能出现大量miss，这属于不固定的时间消耗。
可取的做法：使用带有内核bypass功能的网卡。每个进程或者线程都独占一个cpu核【isolcpus和irqbalance的细节见注释3】，并且不停地轮询，用以保证快速响应。尽量避免任何可能导致阻塞的事件（如mutex），某些注定很慢的活动（比如把log写到磁盘上）应该被独立出来放到别的cpu上，不能影响主线程。
性能测试：网上有一篇博客[tsunanet, 2010]测试了mode switch、thread switch、process switch的耗时，但是这篇文章太早了，以后我要用我的新cpu重新测一下。这篇博客里面，系统调用只需要<100ns，线程/进程切换需要>1us（不包括缓存miss的时间）。
3.使用共享内存作为唯一的IPC机制
相关的知识背景：共享内存只有在初始化的时候有一些系统调用，之后就可以像访问正常内存一样使用了。其他IPC机制（管道、消息队列、套接字）则是每次传输数据时都有系统调用，并且每次传输的数据都经历多次拷贝。因此共享内存是最快的IPC机制。
可取的做法：使用共享内存作为唯一的IPC机制。当然，可能需要手动实现一些东西来保证共享的数据在多进程下是安全，我们是自己实现了无锁内存池、无锁队列和顺序锁【关于seqlock的疑点见注释1】。
性能测试：我使用了boost中的Interprocess库和Lockfree库，在共享内存上建立了一个spsc队列，然后用这个队列来传送数据，代码参考了stackoverflow上的一个答案[sehe, 2014]。我传送的数据是一个8字节整数，延时是153(sd61)ns。至于其他IPC机制，我在[cambridge, 2016]看到了一些性能测试结果，通常是要几微秒到几十微秒不等。
4.传递消息时使用无锁队列
相关的知识背景：我只关注基于数组的无锁队列，其中：spsc队列是wait-free的，不论是入队出队都可以在确定的步数之内完成，而且实现时只需要基本的原子操作【为什么这很重要见注释7】；mpmc队列的实现方式则多种多样，但都会稍微慢一点，因为它们需要用一些比较重的原子操作（CAS或者FAA），而且有时它们需要等待一段不确定的时间直到另一个线程完成相应操作；另外，还有一种multi-observer的『广播队列』，多个读者可以收到同一条消息广播，这种队列也有sp和mp类型的，可以检查或者不检查overwrite；最后，还有一种队列允许存储不定长的消息。
可取的做法：总的来说，应该避免使用mp类型的队列，举例：如果要用mpsc队列，可以使用多个spsc来达成目的，并不需要mp队列；同理，如果是消息广播，也可以使用多个sp队列来取代一个mp队列；如果广播时observer只想订阅一部分消息，那么可以用多个spsc+有计数功能的内存池【具体做法见注释2】；如果要求多个观察者看到多个生产者的消息，并且顺序一致，那只能用mp队列了。总结一下，mp类型的队列应该尽量避免，因为当多个生产者同时抢占队列的时候，延时会线性增长。
性能测试：我写了一个mp类型的广播队列，传输的数据是8字节int，当只有一个生产者时，传输的延时是105(sd26)ns。增加观察者会使延时略微变大，增加生产者会使延时急剧变大（我用rdtsc指令控制不同生产者同时发送消息）。对于这个队列来说，它的延时只略高于跨核可视延时【测试结果见注释8】，所以应该算是不错了。
5.考虑缓存对速度的影响
相关的背景知识：现在的机器内存是十分充足的，但是缓存还是很小，因此所有节省内存的技巧都还有用武之地。
可取的做法：尽量让可能被同时使用的数据挨在一起；减少指针链接（比如用array取代vector，因为链接指向的地方可能不在缓存里）；尽量节省内存（比如用unique_ptr<Data[]>取代vector<Data>，比如成员变量按照从大到小排序，比如能用int8的地方就不用int16）；指定cpu affinity时考虑LLC缓存（同核的两个超线程是共享L1，同cpu的两个核是共享L3，不同NUMA核是通过QPI总线）；会被多个核同时读写的数据按照缓存行对齐（避免false sharing）。
【注释1】：有一篇惠普的论文[Hans-J.Boehm, 2012]大致叙述了顺序锁的实现方法，但是那里面有两点让我感到困惑。一是需要用到thread_fence，这在某些cpu上可能会影响性能(x86似乎没影响)；二是被保护的内容也必须是原子变量(可以是多个原子变量，所以被保护的内容可以很长)。但这是我见过的唯一一个符合C++标准的SeqLock的实现。
【注释2】：如果有M个生产者要发消息给N个观察者，可以建M*N个spsc队列和M个内存池，观察者只能读内存池里的数据，只有对应的那一个生产者可以修改内存池。我感觉这样应该会更快，但我没测过。
【注释3】：isolcpus可以隔离出一些cpu，避免其他线程被调度到这些cpu上执行。此外，设置irq affinity可以让一些cpu尽量避免响应中断，但在/proc/interrupts里面仍然有一些项目是避免不了的，而cpu处理中断时，用户程序会有一段时间（有时高达几十微秒）无法响应，我们没法解决这个问题。
【注释4】：在不同的时间点，ping的结果会有很大差异。交易时间段内ping出来的结果是30us，其它时间段ping出来的结果可能是几百微秒。我不知道这是什么原因，可能是期货公司为了省电关掉了某些东西？
【注释6】：我们要在共享内存上使用内存池，所以不得不自己写一个。我写的内存池只能分配固定尺寸的内存块，但是用户可以建立好几个内存池，用来分配不同的尺寸。实现的过程中有两个要点。一是用无锁链表来保存空闲的内存块；二是每个线程内部有一个缓冲区，所以真正取内存块的时候是没有CAS操作的。
【注释7】：在Intel x86的cpu上，如果C++中的内存顺序只用了acquire和release，那么编译出来的汇编代码里面不会有任何内存栅栏指令；如果同时也没有RMW（读-改-写）指令的话，无锁的代码编译出来就会像是普通的代码一样了。事实上，spsc队列的延时几乎等于跨核可视延时。
【注释8】：跨核可视延时：对于一个共享变量来说，如果有一个核上面的进程或者线程修改了这个变量，另一个核需要过一段时间才能看到这个修改，这段时间被称作跨核可视延时。我不确定在这段时间内，第二个核是会看到旧的数据还是这条指令会执行很久。在我的机器上，对于同一个cpu上的不同核心，这个值是96(sd14)ns。另外，对于同一个核心上的不同超线程，这个值应该会更小；对于同一台机器上的不同cpu，这个值应该会更大。
[cambridge, 2016]：Computer Laboratory
[Gabriele Paoloni, 2010]：Code Execution Times: IA-32/IA-64 Instruction Set Architecture
[Hans-J.Boehm, 2012]：http://www.hpl.hp.com/techreports/2012/HPL-2012-68.pdf
[sehe, 2014]：Shared-memory IPC synchronization (lock-free)
[tsunanet, 2010]：http://blog.tsunanet.net/2010/11/how-long-does-it-take-to-make-context.html