fasthttp 高性能原理

fasthttp 性能可以达到net/http 的十倍，fasthttp 作者在已经有了net/http的情况下重头开发fasthttp的原因是因为net/http 的api限制了许多优化机会，fasthttp性能如此高的原因最关键的两个字就是“复用”，能够复用的对象绝不重新开辟分配内存，这减少了大量的内存分配，也减轻了GC压力，尤其是QPS上去后会更加的明显，本篇文章先从宏观角度来了解下fasthttp 如此高性能的原理，我相信读者有了宏观上的了解之后在去读fasthttp相关的源码会更加容易理解。

goroutine 的复用

fasthttp 自己实现了goroutine pool ，在收到连接后会去goroutine pool 里尝试获取空闲的goroutine 来处理这个连接，在连接完毕后会将goroutine 返还至goroutine pool 。而net/http 的实现是简单粗暴的一个连接一个goroutine ，这样的模式我们之前在讲gnet 的时候提到过，绝大多数情况下没有问题，但一旦面临海量连接会导致内存占用高、调度的延时等问题，而且理论上连接数越多这种情况会越明显。fasthttp gourtine 复用的这部分源代码也是下一节的重点分析对象，会带大家从源码来分析fasthttp 是如何复用goroutine 的。

内存变量复用

fasthttp 内部用了大量的sync.Pool，为多次使用的变量节省了大量的内存申请和拷贝开销。在整个框架的实现中，以下几个最常用的对象都用了对象池来实现一个复用的效果（这次请求用完之后归还对象池，下一个请求来了直接用）：

• context Pool ，用来复用requestCtx,requestCtx 是fasthttp 里面最常用的数据结构，是整个请求的上下文。
• reader buffer pool ，读取HTTP请求连接，储存用户请求数据。
• writer buffer pool ，响应用户请求，储存请求响应数据。
• BytesBuffer pool，把[]byte池化处理

除此fasthttp 为了更好的内存复用还做了一些优化，比如在需要kv 数据类型的地方，用slice 来代替map ，可能有些同学会感到很疑惑，slice 的查找效率是O(n), 而map 的查找效率是O(1)，这不是反向优化吗。实际上不是这样的，fasthttp 作者就为什么使用slice 来代替map 给出了以下几点理由：

• 通常 headers、query 参数或 cookies 的数量很少。因此，可理解为对查询效率影响甚微，毕竟 hash map 计算也要耗时的，还要解决 "碰撞" 问题
• 在这个场景下，相比于map，slices 提供了更好的性能。（slice 内存利用率更高，map key value内存分布不连续）
• slic能保存加入的每一项的顺序,而 无法保证。