パフォーマンスDとGo for Webの比較

こんにちは、Habr!

私はすぐにWebアプリケーションを開発する必要があり、特にDやGoなどの言語があるため、インタープリター言語で書くことを何とかする必要がないため、Webで作業するときのパフォーマンスを比較したいという要望がありました(ネットワーク上でテストを見つけることができませんでした新鮮です)。 Dの場合、これはvibe.dであり、Goの場合、理解しているとおり、フレームワークは使用されません。 Go以来、私は「何も」知らないことを知っています。テストアプリケーションは、単にテキスト(データベース、複雑なルーティング、画像なし)を含むページを提供するだけです。

負荷はApache Benchmarkを使用して与えられました。



Dのアプリケーションは標準のバイブアプリケーションです。
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); } 
そして
ビュー/ 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/ (site_test_goの場合は8100)

始めましょう

Apacheベンチマーク

ドキュメントの長さと一致するように、インデックスファイル用の少し異なるコードが作成されました(明らかに、バイブは応答ヘッダーで何かを伝えます)
ドランゴラン
Server Software: vibe.d/0.7.28
Server Hostname: localhost
Server Port: 8101

Document Path: /
Document Length: 182 bytes

Concurrency Level: 200
Time taken for tests: 4.481 seconds
Complete requests: 50000
Failed requests: 0
Total transferred: 16450000 bytes
HTML transferred: 9100000 bytes
Requests per second: 11157.90 [#/sec] (mean)
Time per request: 17.925 [ms] (mean)
Time per request: 0.090 [ms] (mean, across all concurrent requests)
Transfer rate: 3584.91 [Kbytes/sec] received

Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 8 33.2 7 1009
Processing: 2 10 3.7 9 207
Waiting: 1 8 3.5 7 205
Total: 3 18 33.4 17 1020

Percentage of the requests served within a certain time (ms)
50% 17
66% 18
75% 18
80% 18
90% 19
95% 23
98% 29
99% 30
100% 1020 (longest request)

Server Software:
Server Hostname: localhost
Server Port: 8100

Document Path: /
Document Length: 182 bytes

Concurrency Level: 200
Time taken for tests: 4.263 seconds
Complete requests: 50000
Failed requests: 0
Total transferred: 14950000 bytes
HTML transferred: 9100000 bytes
Requests per second: 11728.36 [#/sec] (mean)
Time per request: 17.053 [ms] (mean)
Time per request: 0.085 [ms] (mean, across all concurrent requests)
Transfer rate: 3424.59 [Kbytes/sec] received

Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 8 14.9 7 1011
Processing: 2 9 2.3 9 211
Waiting: 1 7 2.4 7 210
Total: 10 17 15.1 16 1020

Percentage of the requests served within a certain time (ms)
50% 16
66% 17
75% 18
80% 18
90% 19
95% 20
98% 21
99% 22
100% 1020 (longest request)



記憶

gnome-system-monitorを使用して測定を実行しました
ドランゴラン
最初のリクエストの前メモリ:680.0KiB
仮想:907.5MiB
居住者:10.2MiB
書き込み可能:343.3MiB
共有:9.5MiB
メモリ:888.0KiB
仮想:110.8MiB
居住者:5.2MiB
書き込み可能:35.7MiB
共有:4.4MiB
abを実行した後メモリ:19.2MiB
仮想:9.5GiB
居住者:28.7MiB
書き込み可能:9.0GiB
共有:9.6MiB
メモリ:6.5MiB
仮想:1.3GiB
居住者:12.5MiB
書き込み可能:1.0GiB
共有:5.9MiB


CPU使用率

gnome-system-monitorを使用して測定を実行しました
ドランゴラン


ソフトウェアバージョン

apr-util-1.5.4-1.fc22.x86_64

DMD64 Dコンパイラv2.071.0
2016年5月22日にビルドされたDUBバージョン0.9.25
バイブ0.7.28

goバージョンgo1.5.4 linux / amd64

結論

ツールのパフォーマンスは実質的に同じです(実際、私は驚いています)。
Dメモリの不調:Goの約3倍。
プロセッサ使用率のグラフに基づいて、Goのタスクスケジューラがより適切に配置されていることを結論付けることができます。コアの負荷をすぐに均等に分散しますが、平均してDのCPU負荷は低くなります。
Dアプリケーションのコンパイルに時間がかかることに注意してください(Web開発の場合、これは不快な瞬間になる可能性があります)。

PS:これはWebパフォーマンスの最初の実験です(一般にWebサインはまだよくありません)。したがって、測定方法や初期条件のエラーを指摘していただければ幸いです=)



UPD:
ここで、おそらくこのテスト全体で最大の間違いであることに気付きました。 vibe-dはlibevent2を使用し、このテストではそのパフォーマンスを正確に評価します(valgrind / callgrindの結果から判断します)。 そして、私が理解しているように、独自のイベントループ実装があり、サードパーティのライブラリはそのまま使用するよりもパフォーマンスが優れています(valgrindの実行可能ファイルに文字が含まれるようにgoをコンパイルする方法を理解していませんでした、 go build -ldflags "-w" -gcflags "-N -l"は役に立ちませんでした)。

しかし、とにかく、「箱から出してすぐに」構成をテストすることは、私にとって個人的に興味深いものでした。

Source: https://habr.com/ru/post/J303590/


All Articles