Низкая производительность html/template в Go lang, есть обходной путь?

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

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

Пожалуйста, протестируйте этот код и сообщите о результатах.

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

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

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

Существует эталонный тест шаблона, который вы можете проверить на странице goTemplateBenchmark. Лично я считаю, что Hero лучше всего сочетает эффективность и удобочитаемость.