performance - http.Handle wrapper pattern -> 堆栈会膨胀吗？

Question

我正在做第一个生产 web 服务，所以我对这门语言和一些概念/模式还很陌生。

我的问题与处理程序有关，本质上是如何在不降低性能的情况下提取重复代码。

我遇到了包装 http.Handle 或 http.HandlerFunc 以清理代码的模式。例如这篇博文在这里使用适配器模式 https://medium.com/@matryer/writing-middleware-in-golang-and-how-go-makes-it-so-much-fun-4375c1246e81#.hvsc236iv

它可能会以这样的方式结束(从 blob 帖子中复制):

http.Handle("/", Adapt(indexHandler, AddHeader("Server", "Mine"),
                                 CheckAuth(providers),
                                 CopyMgoSession(db),
                                 Notify(logger), 
                               )

这基本上是一个深度嵌套的函数调用。

我的问题是堆栈中发生了什么以及服务的性能如何？使用此模式，每个用户请求都会向堆栈添加至少 5 个堆栈帧。当流量很高时，这是可以接受的还是会对性能产生负面影响？

Answer 1

链接中间件基本上只是让链的处理程序调用下一个，通常基于是否一切顺利的条件。或者在另一种方法中，一些外部机制可能会逐个调用处理程序。

但是，所有事情都归结为将调用处理程序。 Handler.ServeHTTP()方法如下所示:

type Handler interface {
    ServeHTTP(ResponseWriter, *Request)
}

一个带有 2 个参数且没有返回值的简单方法。参数类型为 http.ResponseWriter (接口(interface)类型)和 *http.Request (指针类型)。

因此，调用处理程序的 ServeHTTP() 涉及两件事:制作其参数的副本 - 因为它们很小，所以速度很快，并且实际进行调用(处理堆栈更新，例如创建一个新的堆栈框架，记录返回地址，保存使用过的寄存器，并执行被调用的函数)——这也非常快(参见答案末尾的引用)。

那么你应该担心调用函数吗？不。与包含所有内容的处理程序相比，这会降低性能吗？是的。差异显着吗？不会。为 HTTP 请求提供服务可能需要数百毫秒(包括网络延迟)。在您的处理程序中调用 10 个函数不会使其明显变慢。

如果您担心函数调用导致的性能损失，那么您的应用将包含一个 main() 函数。显然没有人想要那样。您创建函数将最初的大问题分解为较小的问题(递归地直到它“足够小”以独立存在)，您可以监督和重用和< em>独立于其他人进行测试，然后您将您的大问题从较小的问题中组装出来。这实际上不是性能问题，而是可维护性 和可重用性。您真的要将检查用户身份的 100 行代码复制到所有 10 个不同的处理程序吗？

最后一件事。您是否应该担心“消耗”堆栈(导致堆栈溢出错误)？答案是不。一个 goroutine 以一个 4096 字节的小堆栈开始，它可以根据需要增长和收缩，而没有用完的风险。在 Why is a Goroutine’s stack infinite? 阅读更多相关信息也详见 FAQ: Why goroutines instead of threads?

To make the stacks small, Go's run-time uses resizable, bounded stacks. A newly minted goroutine is given a few kilobytes, which is almost always enough. When it isn't, the run-time grows (and shrinks) the memory for storing the stack automatically, allowing many goroutines to live in a modest amount of memory. The CPU overhead averages about three cheap instructions per function call.