Golang в Revel и Gin-gonic почему-то работает медленнее PHP :-/

Например, у php гораздо быстрее регэкспы, чем в go.

Например, у php гораздо быстрее регэкспы, чем в go.

Там всего один, совсем простой регексп. Он, по идее, занимает совсем доли процента загрузки на общем фоне :)

подозреваю, что html/template может быть тоже не образцом оптимизированности. Можешь погуглить альтернативные реализации того и другого. Маршалинг-анмаршаллинг json, например, в альтернативных реализациях быстрее, чем в стандартной библиотеке.

Он, по идее, занимает совсем доли процента загрузки на общем фоне :)

Профилируй, чтобы не гадать на кофейной гуще.

А голый Go? Выложи примеры своего кода куда-нибудь. А то так — это гадание на кофейной гуще.

По хорошему ты парзишь templates только одни раз, а потом только используешь. Так же с regex (если они вообще нужны).

Но если же конечно при каждом запросе в обработчике парзить всё по новой — то ничего удивительного.

Где код?

А голый Go?

Ну, логика подсказывает, что голый Go будет куда быстрее :)

Сейчас проверил, Gin без парсинга html выдаёт до 12 r/s, как и PHP.

Выложи примеры своего кода куда-нибудь.

Да там кода-то... Вот пример с Gin: https://gist.github.com/Balancer/54d6d3dff3139608e423

Вот контроллер Revel:
https://gist.github.com/Balancer/5ab4b97249af7d449522

Попробуй в коде перед запуском сервера сказать

runtime.GOMAXPROCS(4);

До 1.5 Golang работал на одном ядре по-умолчанию, а это выставит 4 штуки.

Попробуй в коде перед запуском сервера сказать

Я в коде Gin играл с этим (в коде на gist как раз стоит один из вариантов) — не влияет. Переменную окружения GOMAXPROCS тоже пробовал ставить в 10 (на машине, вообще, 24 ядра) никакого эффекта.

go 1.5.1

Про примерс gin: во-первых, зачем компилировать regexp при каждом запросе? во-вторых, про небыстрый json из стандартной библиотеки я уже говорил, но думаю, тут дело не в нем. Ссылку как профилировать я дал.

Про revel то же самое: сделай rp глобальной переменной, чтобы твой регэксп был скомпилирован до запроса.

во-первых, зачем компилировать regexp при каждом запросе?

На скорости не сказывается.

во-вторых, про небыстрый json из стандартной библиотеки я уже говорил, но думаю, тут дело не в нем.

Да, я делал пример с прямым возвратом строки:

package main

import "github.com/gin-gonic/gin"
import "runtime"
import "net/http"

func main() {

    runtime.GOMAXPROCS(runtime.NumCPU())

    router := gin.Default()
    router.GET("/chart/1000.php", func(c *gin.Context) {
            c.String(http.StatusOK, "Hello world")
    })

    router.Run("127.0.0.1:18080")
}

конпеляция регэкспа на каждый запрос

Есть подозрение, что ты не понимаешь, что измеряешь. Это производительность чего?

Нет смысла писать на го как на пхп.

Если тебе нужна скорость для бэнчмарков - бери https://github.com/valyala/fasthttp

Ну и, если уж так тупо в лоб измерять, сколько памяти отжирает при этом го и сколько пхп?

Это производительность чего?

Простых запросов.

Нет смысла писать на го как на пхп.

Ну так как мне написать более быстрый вариант? :)

Задача простая — есть html-шаблон. Нужно проставить вычисленные значения и вернуть результат.

Ну и, если уж так тупо в лоб измерять, сколько памяти отжирает при этом го и сколько пхп?

Не важно в моём случае. Всё равно 256Гб.

Я прекрасно понимаю, что на сложной задаче или с числодробилками Go уделает PHP. Я не понимаю, почему скорость одного порядка на простой задаче :)

Например, потому, что ты меряешь пропускную способность сетевого стека (или погоду на марсе), которая от языка не зависит. Профилируй, чтобы понять, что у тебя тормозит.

как мне написать более быстрый вариант? :)

Про вынесение компиляции регэкспа в глобальную переменную для дальнейшего использования уже написал, про профилирование - тоже. Если это для тебя не ответ, значит ответа для тебя не завезли.

Задача простая — есть html-шаблон. Нужно проставить вычисленные значения и вернуть результат.

Щас напишут, что го мол не для такой фигни, а вот для больших дел он ого-го. А на деле в большой фигне может быть еще больше затыков, ведь эти фреймворки никто толком не использует, сколько там граблей раскидано неизвестно.

Я прекрасно понимаю, что на сложной задаче или с числодробилками Go уделает PHP. Я не понимаю, почему скорость одного порядка на просто

Сам написал... Ты что, правда в это веришь? Ну вот смотри, он уже на простейшей задаче просасывает, в тред уже пришли хардкорные микрооптимизаторы. Нафиг это надо?

Я не понимаю, почему скорость одного порядка на простой задаче :)

Дык, может оно в сетку уперлось?

Вынеси в обоих случаях

rp := regexp.MustCompile("[^A-Z]+")

На PHP код тоже хотелось бы взглянуть.

Можно попробовать в релизе

gin.SetMode(gin.ReleaseMode)

А кто тебе сказал что PHP должен быть медленным?

интерпретатор вс компилятор
динамичекие типы вс статические

теория вс реальность

Gin сам по себе не очень фреймворк. Ребята ушли на учебу и забросили его. Шаблоны в самом Golang не очень то и быстрые.

Рекомендую взять echo а для шаблонов pongo2 (в нем как раз и кеширование есть).

в нем как раз и кеширование есть

Оно из коробки есть:

var tmpls = template.Must(template.ParseGlob("./templates/*"))
func getIndex(c *gin.Context) {
	tmpls.ExecuteTemplate(c.Writer, "index.tmpl", nil)
}
func main() {
	app := gin.Default()
	app.GET("/", getIndex)
	log.Fatal(http.ListenAndServe(":8080", app))
}

А тут и не должен го быть быстрее, го будет на порядок быстрее в real world задачах, где тебе нужно держать коннекты, на пхп много процессов ненаплодишь, а так ты меряешь как сишечка внутри пхп работает на реквестах.

И да, цифры у Go для такого сервера откровенно маленькие, у меня тоже самое на десктопе не первой свежести.

ведь эти фреймворки никто толком не использует, сколько там граблей раскидано неизвестно.

Да, с документацией там швах. Час, наверное, ковырялся, прежде чем получилось что нужно было. И из этого часа 3/4 — гугление.

Дык, может оно в сетку уперлось?

Может быть (хотя оно на локалхосте, но там тоже много ограничений). Завтра/послезавтра продолжу разбираться с оптимизациями.

Вынеси в обоих случаях

Там я приводил пример вообще без регекспа и парсинга шаблонов :)

На PHP код тоже хотелось бы взглянуть.

Там совсем смотреть не на что:

<?php
    $type = empty($_GET['id']) ? 'EURUSD' : strtoupper(preg_replace('/\W/', '_', $_GET['id']));
?>
<!DOCTYPE html>
<html>
<head>

<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
...
<iframe ... src="http://...?type=<?=$type?>" ... >
...
</body>
</html>

Слышал, что в Revel много магии на рефлекшне. Может быть поэтому тормозит? Попробуй без Revel-а, в стандартной библиотеке Go есть поддержка HTTP, простой API для написания обработчиков и шаблонизатор.

Плюс fmt.Printf убрать

Это моя опечатка :) Он в коде закомментирован, а я, выкладывая в gist тормознул и не строчку стёр (чтобы не мешалась), а комментарий :)

А кто тебе сказал что PHP должен быть медленным?

Объектный Фибоначчи :)

Рекомендую взять echo а для шаблонов pongo2 (в нем как раз и кеширование есть).

Спасибо, посмотрю.

а так ты меряешь как сишечка внутри пхп работает на реквестах

Скорее измеряю, как PHP рождается и умирает. Это же одна из самых громких претензий к классическому PHP. А тут оказывается, что рождающийся и умирающий PHP не уступает живущему Go. Это и удивило.

Слышал, что в Revel много магии на рефлекшне. Может быть поэтому тормозит?

Если бы тормозил Reval, это бы меня не удивило. Удивило, что куда более лёгкий Gin у меня работает медленнее.

А тут оказывается, что рождающийся и умирающий PHP не уступает живущему Go. Это и удивило.

Ты ведь сам понимаешь что невозможно с моделью process per request соревноваться с демонизированным веб сервером, который еще и легкие потоки умеет. Бенчмарки сломаны.

В общем, на упомянутом сервере nginx статику отдаёт со скоростью до 16 тыс rps что явно мало. С сетевыми настройками разбираться будут позже, а вот результаты теста на домашней машине с Gentoo.

— nginx/статика: 26 krps
— php-fpm-5.6.17/hello world: 15 krps
— go-1.5.3/gin/hello world: 20 krps

Тут go шустрее. Но php всё равно поражает. Я как-то привык к тому, что hello world отдаётся на порядок медленнее статики nginx. А тут получается тот же порядок.

Ты ведь сам понимаешь что невозможно с моделью process per request соревноваться с демонизированным веб сервером

Понимаю. И потому крайне удивлён, что php с его идеологией совсем немного отстаёт от статики nginx :)

Версия go какая? Если меньше 1.5, то без runtime.GOMAXPROCS(runtime.NumCPU()) он жрёт только одно ядро и с многоядерностью были проблемки. В 1.5 пофиксили.

А чего тут поражать в php 5.6 встроенный opcache. Компиляции на каждый запрос не происходит, просто выполняется код, который к тому же берется из памяти.

Ну и опять же, все эти бенчи от лукавого. Если уж выкладываете, что-то в паблик, то должны быть видны условия эксперемента. Коды на разных языках, конфиги серверов, версии программного обеспечения и т.д. Иначе болтология.

Если уж выкладываете, что-то в паблик, то должны быть видны условия эксперемента.

ab -n10000 -c100 :)

Коды на разных языках, версии программного обеспечения и т.д.

Это было.

конфиги серверов

Одинаковые внутри одного эксперимента.

есть же для ориентирования https://www.techempower.com/benchmarks , осталось понять, что там с многоядерностью

//c:11155