我正在压力测试（使用loader.io）这种类型的代码在Go中创建一个包含100个项目的数组以及一些其他基本变量并在模板中解析所有这些：
package main
import (
"html/template"
"net/http"
)
var templates map[string]*template.Template
// Load templates on program initialisation
func init() {
if templates == nil {
templates = make(map[string]*template.Template)
}
templates["index.html"] = template.Must(template.ParseFiles("index.html"))
}
func handler(w http.ResponseWriter, r *http.Request) {
type Post struct {
Id int
Title, Content string
}
var Posts [100]Post
// Fill posts
for i := 0; i < 100; i++ {
Posts[i] = Post{i, "Sample Title", "Lorem Ipsum Dolor Sit Amet"}
}
type Page struct {
Title, Subtitle string
Posts [100]Post
}
var p Page
p.Title = "Index Page of My Super Blog"
p.Subtitle = "A blog about everything"
p.Posts = Posts
tmpl := templates["index.html"]
tmpl.ExecuteTemplate(w, "index.html", p)
}
func main() {
http.HandleFunc("/", handler)
http.ListenAndServe(":8888", nil)
}
我对Loader的测试是在1分钟内使用5k并发连接。问题是，在开始测试几秒钟后，我得到了很高的平均延迟（差不多10秒），因此5k成功响应并且测试停止，因为它达到50％的错误率（超时）。
在同一台机器上，PHP提供50k +。
我知道这不是Go性能问题，但可能与html / template有关。当然，Go可以比PHP之类的任何东西更快地管理足够快的计算，但是当把数据解析到模板时，为什么它太可怕了呢？
任何解决方法，或者我可能只是做错了（我是Go的新手）？
P.S。实际上，即使只有一个项目它完全相同... 5-6k并在大量超时后停止。但这可能是因为带有帖子的数组保持相同的长度。
我的模板代码（index.html）：
{{ .Title }}
{{ .Subtitle }}
{{ range .Posts }}
{{ .Title }}
{{ .Content }}
{{ end }}
以下是github.com/pkg/profile的分析结果：
root@Test:~# go tool pprof app /tmp/profile311243501/cpu.pprof
Possible precedence issue with control flow operator at /usr/lib/go/pkg/tool/linux_amd64/pprof line 3008.
Welcome to pprof! For help, type 'help'.
(pprof) top10
Total: 2054 samples
97 4.7% 4.7% 726 35.3% reflect.Value.call
89 4.3% 9.1% 278 13.5% runtime.mallocgc
85 4.1% 13.2% 86 4.2% syscall.Syscall
66 3.2% 16.4% 75 3.7% runtime.MSpan_Sweep
58 2.8% 19.2% 1842 89.7% text/template.(*state).walk
54 2.6% 21.9% 928 45.2% text/template.(*state).evalCall
51 2.5% 24.3% 53 2.6% settype
47 2.3% 26.6% 47 2.3% runtime.stringiter2
44 2.1% 28.8% 149 7.3% runtime.makeslice
40 1.9% 30.7% 223 10.9% text/template.(*state).evalField
这些是在完善代码之后的分析结果（如icza的答案所示）：
root@Test:~# go tool pprof app /tmp/profile501566907/cpu.pprof
Possible precedence issue with control flow operator at /usr/lib/go/pkg/tool/linux_amd64/pprof line 3008.
Welcome to pprof! For help, type 'help'.
(pprof) top10
Total: 2811 samples
137 4.9% 4.9% 442 15.7% runtime.mallocgc
126 4.5% 9.4% 999 35.5% reflect.Value.call
113 4.0% 13.4% 115 4.1% syscall.Syscall
110 3.9% 17.3% 122 4.3% runtime.MSpan_Sweep
102 3.6% 20.9% 2561 91.1% text/template.(*state).walk
74 2.6% 23.6% 337 12.0% text/template.(*state).evalField
68 2.4% 26.0% 72 2.6% settype
66 2.3% 28.3% 1279 45.5% text/template.(*state).evalCall
65 2.3% 30.6% 226 8.0% runtime.makeslice
57 2.0% 32.7% 57 2.0% runtime.stringiter2
(pprof)
答案 0 :(得分：11)
使用html/template的等效应用程序比PHP变体慢的原因有两个主要原因。
首先，html/template提供了比PHP更多的功能。主要区别在于html/template将使用正确的转义规则（HTML，JS，CSS等）自动转义变量，具体取决于它们在生成的HTML输出中的位置（我觉得这很酷！）。
其次html/template渲染代码大量使用具有可变数量参数的反射和方法，它们没有静态编译代码那么快。
引导下面的模板
{{ .Title }}
{{ .Subtitle }}
{{ range .Posts }}
{{ .Title }}
{{ .Content }}
{{ end }}
转换为类似
的内容{{ .Title | html_template_htmlescaper }}
{{ .Subtitle | html_template_htmlescaper }}
{{ range .Posts }}
{{ .Title | html_template_htmlescaper }}
{{ .Content | html_template_htmlescaper }}
{{ end }}
在循环中使用反射调用html_template_htmlescaper会导致性能下降。
已经说过html/template的这个微观基准不应该被用来决定是否使用Go。一旦你添加代码来处理数据库到请求处理程序，我怀疑模板渲染时间几乎不会引人注意。
另外我很确定随着时间的推移，Go反射和html/template包将变得更快。
如果在实际应用中，您会发现html/template是一个瓶颈，仍然可以切换到text/template并为其提供已转义的数据。
答案 1 :(得分：9)
您正在处理数组和结构，两者都是非指针类型，也不是描述符（如切片或地图或通道）。因此传递它们总是创建值的副本，为变量分配数组值会复制所有元素。这很慢并且为GC提供了大量的工作。
此外，您只使用1个CPU内核。要利用更多功能，请将其添加到main()功能：
func main() {
runtime.GOMAXPROCS(runtime.NumCPU())
http.HandleFunc("/", handler)
log.Fatal(http.ListenAndServe(":8888", nil))
}
编辑： 这只是Go 1.5之前的情况。由于Go 1.5 runtime.NumCPU()是默认值。
var Posts [100]Post
分配了一个空格为100 Post的数组。
Posts[i] = Post{i, "Sample Title", "Lorem Ipsum Dolor Sit Amet"}
使用复合文字创建Post值，然后将此值复制到数组中的i元素中。 （冗余）
var p Page
这会创建一个Page类型的变量。它是struct，因此它的内存被分配，其中还包含一个字段Posts [100]Post，因此分配了另一个100元素数组。
p.Posts = Posts
这会复制100元素（一百个结构）！
tmpl.ExecuteTemplate(w, "index.html", p)
这会创建p（类型为Page）的副本，因此会创建另一个100帖子数组，并复制p中的元素，然后传递给ExecuteTemplate()。
由于Page.Posts是一个数组，很可能是在处理它时（在模板引擎中迭代），将从每个元素中复制（没有检查 - 未经验证）。 / p>
加快代码速度的一些事情：
func handler(w http.ResponseWriter, r *http.Request) {
type Post struct {
Id int
Title, Content string
}
Posts := make([]*Post, 100) // A slice of pointers
// Fill posts
for i := range Posts {
// Initialize pointers: just copies the address of the created struct value
Posts[i]= &Post{i, "Sample Title", "Lorem Ipsum Dolor Sit Amet"}
}
type Page struct {
Title, Subtitle string
Posts []*Post // "Just" a slice type (it's a descriptor)
}
// Create a page, only the Posts slice descriptor is copied
p := Page{"Index Page of My Super Blog", "A blog about everything", Posts}
tmpl := templates["index.html"]
// Only pass the address of p
// Although since Page.Posts is now just a slice, passing by value would also be OK
tmpl.ExecuteTemplate(w, "index.html", &p)
}
请测试此代码并报告结果。
答案 2 :(得分：1)
html/template速度慢，因为它使用reflection，但尚未针对速度进行优化。
尝试quicktemplate作为慢html/template的解决方法。目前quicktemplate的{{1}}速度比html/template快20倍以上。源代码。
答案 3 :(得分：0)
PHP并没有同时回复5000个请求。这些请求被多路复用到少数几个串行执行过程。这样可以更有效地使用CPU和内存。 5000个并发连接可能对消息代理或类似事件有意义，对小块数据进行有限处理，但对于进行实际I / O或处理的任何服务都没有意义。如果您的Go应用程序不在某种类型的代理后面，这将限制并发请求的数量，您可能希望自己，也许在处理程序的开头，使用缓冲的通道或等待组，la {{ 3}}
答案 4 :(得分：0)
您可以在goTemplateBenchmark处查看模板基准。就我个人而言，我认为Hero是将效率和可读性最佳结合的人。