Go でこのタイプのコードを (loader.io を使用して) ストレス テストして、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)
}
ローダーを使用した私のテストでは、1 分間で 5,000 の同時接続/秒を使用しています。問題は、テストを開始してから数秒後に、平均レイテンシが高くなり (ほぼ 10 秒)、その結果、5,000 の成功した応答が得られ、50% のエラー率 (タイムアウト) に達したためにテストが停止することです。
同じマシンで、PHP は 50k+ を返します。
Go のパフォーマンスの問題ではなく、おそらく html/template に関連する問題であることは理解しています。もちろん、Go は十分に難しい計算を PHP のようなものよりもはるかに高速に簡単に処理できますが、テンプレートへのデータの解析に関しては、なぜそれほどひどいのでしょうか?
回避策はありますか、またはおそらく私は間違っているだけです(私はGoが初めてです)?
PS実際には1つのアイテムでもまったく同じです... 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)