Доброго времени суток, хабр!
Так как мне скоро предстоит разрабатывать веб-приложение, а писать на интерпретирумых языках как-то нет желания, тем более, что есть такие ЯП как D и Go, возникло желание сравнить их производительность при работе с веб (в сети не нашёл тестов, которые были бы свежими). Для D это vibe.d, а для Go, как я понял, не используются фреймворки. Так как Go я знаю менее чем «никак» решил не выпендриваться: тестовые приложения просто отдают страничку с некоторым текстом (ни баз данных, ни сложного роутинга, ни изображений).
Нагрузка давалась с помощью Apache Benchmark.
Приложение на D это стандартное vibe приложение, нас будут интересовать только
В Go приложении нас интересуют соответствующие файлы
Нагрузка:
Немного различный код index файлов был сделан для соответствия Document Length (видимо vibe передаёт что-то в заголовке ответа)
Замер производился с помощью
Замер производился с помощью
apr-util-1.5.4-1.fc22.x86_64
DMD64 D Compiler v2.071.0
DUB version 0.9.25, built on May 22 2016
vibe 0.7.28
go version go1.5.4 linux/amd64
Производительность инструментов практически не различается (чему я удивлён, на самом деле).
Огорчило потребление памяти у D: практически в 3 раза больше чем у Go.
Исходя из графиков загруженности процессора, можно сделать вывод: планировщик заданий в Go устроен лучше — сразу распределяет нагрузку на ядра поровну, но в среднем загрузка ЦП у D ниже.
Стоит отметить, что приложение на D компилируется дольше (для веб разработки это может быть неприятным моментом).
PS: это мой первый эксперимент с производительностью веб (вообще пока не хорошо с веб знаком), так что буду очень рад, если вы укажите на ошибки в способе измерения и/или начальных условиях =)
UPD:
Вот тут я понял, наверное, самоую большую ошибку, во всей этой проверке. vibe-d использует libevent2 и в этом тесте упирается производительностью именно в него (судя по результатам valgrind/callgrind). А go, как я понял, имеет собственную реализацию event-loop'а, причём сторонние библиотеки даже лучше по производительности чем из коробки (не понял как скомпилировать go, чтобы символы были в исполняемом файле для valgrind,
Но всё-равно, тест конфигураций «из коробки», лично для меня был интересен.
Так как мне скоро предстоит разрабатывать веб-приложение, а писать на интерпретирумых языках как-то нет желания, тем более, что есть такие ЯП как D и Go, возникло желание сравнить их производительность при работе с веб (в сети не нашёл тестов, которые были бы свежими). Для D это vibe.d, а для Go, как я понял, не используются фреймворки. Так как Go я знаю менее чем «никак» решил не выпендриваться: тестовые приложения просто отдают страничку с некоторым текстом (ни баз данных, ни сложного роутинга, ни изображений).
Нагрузка давалась с помощью Apache Benchmark.
Приложение на D это стандартное vibe приложение, нас будут интересовать только
source/app.d
и import vibe.d;
shared static this()
{
auto settings = new HTTPServerSettings;
settings.options |= HTTPServerOption.distribute; // без этой настройки vibe однопоточен
settings.port = 8101;
settings.bindAddresses = ["::1", "127.0.0.1"];
listenHTTP(settings, &index);
}
void index(HTTPServerRequest req, HTTPServerResponse res)
{
auto var = "hello habr";
res.render!("index.dt",var);
}
views/index.dt
сборка: html
head
body
h1 Привет, Хабр!
p D is a systems programming language with C-like syntax.
= var
dub build --build=release
В Go приложении нас интересуют соответствующие файлы
site_test_go.go
и package main
import (
"html/template"
"net/http"
)
type Page struct {
Var string
}
func indexViewer(w http.ResponseWriter, r *http.Request) {
p := Page{Var:"hello habr"}
t, _ := template.ParseFiles("index.html")
t.Execute(w, p)
}
func main() {
http.HandleFunc("/", indexViewer);
http.ListenAndServe(":8100", nil);
}
index.html
сборка: <h1>Привет, Хабр!</h1>
<p>Go is an open source programming language that makes it easy to build simple, reliable, and efficient software.</p>
<div>
{{.Var}}
</div>
go build site_test_go.go
Нагрузка:
ab -c200 -n50000 http://localhost:8101/
(8100 для site_test_go)Начнём
Apache Benchmark
Немного различный код index файлов был сделан для соответствия Document Length (видимо vibe передаёт что-то в заголовке ответа)
dlang | golang |
---|---|
Server Software: vibe.d/0.7.28 |
Server Software: |
Память
Замер производился с помощью
gnome-system-monitor
dlang | golang | |
---|---|---|
до первого запроса | memory: 680.0KiB virtual: 907.5MiB resident: 10.2MiB writable: 343.3MiB shared: 9.5MiB |
memory: 888.0KiB virtual: 110.8MiB resident: 5.2MiB writable: 35.7MiB shared: 4.4MiB |
после запуска ab | memory: 19.2MiB virtual: 9.5GiB resident: 28.7MiB writable: 9.0GiB shared: 9.6MiB |
memory: 6.5MiB virtual: 1.3GiB resident: 12.5MiB writable: 1.0GiB shared: 5.9MiB |
Загрузка процессора
Замер производился с помощью
gnome-system-monitor
dlang | golang |
---|---|
Версии ПО
apr-util-1.5.4-1.fc22.x86_64
DMD64 D Compiler v2.071.0
DUB version 0.9.25, built on May 22 2016
vibe 0.7.28
go version go1.5.4 linux/amd64
Выводы
Производительность инструментов практически не различается (чему я удивлён, на самом деле).
Огорчило потребление памяти у D: практически в 3 раза больше чем у Go.
Исходя из графиков загруженности процессора, можно сделать вывод: планировщик заданий в Go устроен лучше — сразу распределяет нагрузку на ядра поровну, но в среднем загрузка ЦП у D ниже.
Стоит отметить, что приложение на D компилируется дольше (для веб разработки это может быть неприятным моментом).
PS: это мой первый эксперимент с производительностью веб (вообще пока не хорошо с веб знаком), так что буду очень рад, если вы укажите на ошибки в способе измерения и/или начальных условиях =)
для любителей языка D
UPD:
Вот тут я понял, наверное, самоую большую ошибку, во всей этой проверке. vibe-d использует libevent2 и в этом тесте упирается производительностью именно в него (судя по результатам valgrind/callgrind). А go, как я понял, имеет собственную реализацию event-loop'а, причём сторонние библиотеки даже лучше по производительности чем из коробки (не понял как скомпилировать go, чтобы символы были в исполняемом файле для valgrind,
go build -ldflags "-w" -gcflags "-N -l"
не помогло).Но всё-равно, тест конфигураций «из коробки», лично для меня был интересен.