rustwarp比gofasthttp要快数倍

　　上周我发现了关于超性能的帖子。它表示rusttokiohyper性能高于gohttp。这是意料之中的，但有一条评论与fasthttp相比，其中rust的表现稍差。
　　我决定自己执行基准测试。使用以下命令在AWSr5n。8xlarge实例上执行所有基准测试：wrkt16c1000d120shttp：127。0。0。1：8080
　　gofasthttp代码：包主导入（github。comvalyalafasthttp）funcfastHTTPHandler（ctxfasthttp。RequestCtx）｛ctx。Success（applicationjson，〔〕byte（Welcome！））｝funcmain（）｛将普通函数传递给fasthttpfasthttp。ListenAndServe（：8080，fastHTTPHandler）｝
　　生锈扭曲代码：使用扭曲：：过滤器；使用http：：header：：｛HeaderValue，HeaderName｝；〔tokio：：main〕asyncfnmain（）｛letjsonHeaderValue：：fromstatic（applicationjson）；让serverkeyHeaderName：：fromstatic（server）；让服务器HeaderValue：：fromstatic（rusthttp）；letrouteswarp：：any（）。map（Welcome！）。with（warp：：reply：：with：：header（http：：header：：CONTENTTYPE，json））。with（warp：：回复：：with：：header（serverkey，server））；warp：：serve（routes）。run（（〔127，0，0，1〕，8080））。await；｝
　　请注意，需要额外的标头来匹配fasthttp实现。
　　初始基准测试结果
　　去快速http：请求秒：1153173。95传输秒：146。27MB
　　生锈翘曲：请求秒：1044974。17传输秒：132。54MB
　　fasthttp比rust版本高出10左右！
　　优化rust版本
　　很少有已知的技巧可以使rust版本更好地工作。让我们一步一步地应用它们，看看我们能走多远。
　　启用LTO
　　LTO是一种链接时优化，可减少生成的二进制大小并提高性能。了解有关LTO的更多信息。请求秒：1099343。12传输秒：139。44MB
　　与初始版本相比，我们获得了5的收益。
　　使用Jemalloc
　　默认情况下，rust代码使用libc内存分配器，通常不建议将其用于高负载的关键应用程序。有很多替代分配器。根据我的经验，jemalloc在性能和内存利用率方面是最好的。了解有关使用jemalloc的更多信息。请求秒：1119851。69传输秒：142。04MB
　　与LTO版本相比，我们得到了1。8。
　　启用不稳定的管道
　　带有wrk的Benchmark是一个非常简单的HTTP1小明文测试。这种基准有一些细节。让我们unstablepipeline在warp实例上启用。请求秒：1163136。54传输秒：147。53MB
　　与LTOjemalloc版本相比，我们获得了额外的3。8。
　　太好了，在这一步我们已经超越了fasthttp！
　　修复一些tokio
　　让我们检查一下火焰图，看看运行代码是否有明显的无效性。我不会发布它，以免叙述过多。
　　引起我注意的特殊功能是wake0（见这里）。常量NUMWAKERS：使用大小32；让mutwakers：〔OptionWaker；NUMWAKERS〕默认：：default（）；
　　该wakers数组是在每个函数调用上创建的，用于收集所有需要通知并实际通知它们的唤醒者。我开始使用这段代码，并意识到减少会NUMWAKERS提高性能！让我们在这里注意，它是一个数组（不是vec），它是在堆栈上分配的，所以不会发生分配。性能不足的原因是rust在初始化数组时，会将None值复制到数组的每个槽中。NUMWAKERS当增加时，这会导致减速。
　　让我们尝试使用相对较新的MaybeUnint结构来修复它。我们需要创建一个MaybeUnint：：unint（）。assumeinit（）包含所有元素的数组MaybeUnint。在这里了解更多。请注意，我们不再需要Option了。请参阅PR与实现。请求秒：1196535。29传输秒：151。77MB
　　我们获得了额外的2。8，并且以3。7的成绩超过了gofasthttp！
　　什么做得不好
　　我尝试了更多技巧，但没有显示出有意义的影响：在http标头中使用aHash而不是FNV。虽然预计aHash的性能会优于FNV，但实际上我发现性能略有下降。尝试编译，RUSTFLAGS’Ctargetcpunative’但显示严重退化10减少SystemTime：：now（）hyper中的调用次数。Hyper需要生成Date标头。它使用优化以每秒一次以RFC7231格式呈现日期，但它仍然执行调用以检索每个HTTP调用的时间。我可以观察到大约0。6的时间花在clockgettime火焰图上。可能的优化是缓存时间并在每个线程停放在tokio中重置一次。有一个未解决的问题。我发现实现起来有点困难，所以我在hyper中注释掉了渲染的Date重新生成。它没有显示出任何稳定的改善。