Подтвердить что ты не робот

Медленная производительность html/template в Go lang, любое обходное решение?

Я испытываю стресс (с 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 использует 5k одновременных подключений/с до 1 минуты. Проблема заключается в том, что через несколько секунд после начала теста я получаю высокую среднюю задержку (почти 10 секунд) и, как результат, 5k успешных ответов и тест останавливается, потому что он достигает скорости ошибки 50% (тайм-ауты).

На той же машине PHP дает 50k +.

Я понимаю, что это не проблема производительности, но, вероятно, что-то связанное с html/template. Go может легко управлять достаточно сложными вычислениями намного быстрее, чем что-либо вроде PHP, но когда дело доходит до разбора данных в шаблон, почему это так ужасно?

Любые обходные пути, или, возможно, я просто делаю это неправильно (я новичок в Go)?

P.S. На самом деле даже с 1 пунктом он точно такой же... 5-6k и останавливается после огромного количества тайм-аутов. Но это, вероятно, потому, что массив с сообщениями остается одной длины.

Мой код шаблона (index.html):

{{ .Title }}
{{ .Subtitle }}

{{ range .Posts }}
        {{ .Title }}
        {{ .Content }}
{{ end }}

Здесь результат профилирования github.com/pkg/profile:

[email protected]:~# 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):

[email protected]:~# 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)
4b9b3361

Ответ 1

Есть две основные причины, по которым эквивалентное приложение, использующее 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 и предоставить ему уже экранированные данные.

Ответ 2

Вы работаете с массивами и структурами, которые являются не указательными типами, и не являются дескрипторами (например, срезами или картами или каналами). Поэтому их передача всегда создает копию значения, присваивая значение массива переменной, копируя все элементы. Это медленно и дает огромную работу GC.


Также вы используете только 1 ядро ​​процессора. Чтобы использовать больше, добавьте это в свою функцию 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 - это массив, скорее всего, когда он будет обработан (переработан в движке шаблона), копия будет сделана из каждого элемента (не проверена - не проверена).

Предложение для более эффективного кода

Некоторые вещи, чтобы ускорить ваш код:

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 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)
}

Пожалуйста, проверьте этот код и отчитайте результаты.

Ответ 3

html/template медленный, потому что он использует reflection, который еще не оптимизирован для скорости.

Попробуйте quicktemplate как обход медленного html/template. В настоящее время quicktemplate более чем в 20 раз быстрее, чем html/template в соответствии с эталоном из его исходного кода.

Ответ 4

PHP не отвечает одновременно с 5000 запросами. Запросы мультиплексируются в несколько процессов для последовательного выполнения. Это позволяет более эффективно использовать как процессор, так и память. 5000 одновременных соединений могут иметь смысл для брокера сообщений или аналогичных, делая ограниченную обработку небольших фрагментов данных, но это не имеет никакого смысла для любой службы, выполняющей реальные операции ввода-вывода или обработки. Если ваше приложение Go не находится за прокси-сервером какого-либо типа, который будет ограничивать количество одновременных запросов, вы захотите сделать это самостоятельно, возможно, в начале вашего обработчика, используя буферный канал или группу ожидания, a la https://blakemesdag.com/blog/2014/11/12/limiting-go-concurrency/.