{"id":4839,"date":"2023-01-23T09:14:33","date_gmt":"2023-01-23T08:14:33","guid":{"rendered":"https:\/\/launix.de\/launix\/?p=4839"},"modified":"2023-03-02T10:26:44","modified_gmt":"2023-03-02T09:26:44","slug":"when-the-benchmark-is-too-slow-golang-http-server-performance","status":"publish","type":"post","link":"https:\/\/launix.de\/launix\/en\/when-the-benchmark-is-too-slow-golang-http-server-performance\/","title":{"rendered":"When the benchmark is too slow… (golang http server performance)"},"content":{"rendered":"\n

Just a shmankerl from the daily life of a developer.<\/p>\n\n\n\n\n\n\n\n

When I tested memcp performance, I ran into the problem that my benchmark tool was too slow.<\/p>\n\n\n\n

The goal was to test golang’s http server throughput in memcp. The setup is fairly easy: golangs net\/http library opens up a simple http server with a custom handler. The custom handler executes a scheme script that will handle the request. When the path equals “\/foo”, a handcoded query on the storage engine (indexed table scan over 9,000 items and print out of 12 result lines) is run.<\/p>\n\n\n\n

I decided to use Apache’s tool ab<\/code> for benchmarking.<\/p>\n\n\n\n

This is the result of running ab with 1,000,000 requests:<\/p>\n\n\n\n

carli@launix-MS-7C51<\/b><\/font>:~\/projekte\/memcp<\/b><\/font>$ ab -n 1000000 -c 100 http:\/\/localhost:4321\/foo\nThis is ApacheBench, Version 2.3 <$Revision: 1879490 $>\nCopyright 1996 Adam Twiss, Zeus Technology Ltd, http:\/\/www.zeustech.net\/\nLicensed to The Apache Software Foundation, http:\/\/www.apache.org\/\n\nBenchmarking localhost (be patient)\nCompleted 100000 requests\nCompleted 200000 requests\nCompleted 300000 requests\nCompleted 400000 requests\nCompleted 500000 requests\nCompleted 600000 requests\nCompleted 700000 requests\nCompleted 800000 requests\nCompleted 900000 requests\nCompleted 1000000 requests\nFinished 1000000 requests\n\n\nServer Software:        \nServer Hostname:        localhost\nServer Port:            4321\n\nDocument Path:          \/foo\nDocument Length:        432 bytes\n\nConcurrency Level:      100\nTime taken for tests:   31.336 seconds\nComplete requests:      1000000\nFailed requests:        0\nTotal transferred:      535000000 bytes\nHTML transferred:       432000000 bytes\nRequests per second:    31912.48 [#\/sec] (mean)\nTime per request:       3.134 [ms] (mean)\nTime per request:       0.031 [ms] (mean, across all concurrent requests)\nTransfer rate:          16673.02 [Kbytes\/sec] received\n\nConnection Times (ms)\n              min  mean[+\/-sd] median   max\nConnect:        0    1   0.2      1       3\nProcessing:     0    2   0.4      2       7\nWaiting:        0    1   0.4      1       7\nTotal:          0    3   0.4      3       9\n\nPercentage of the requests served within a certain time (ms)\n  50%      3\n  66%      3\n  75%      3\n  80%      3\n  90%      4\n  95%      4\n  98%      4\n  99%      4\n 100%      9 (longest request)<\/pre>\n\n\n\n
30,000 requests per second sounds really great, dosen’t it? But take a closer look at htop<\/code><\/p>\n\n\n\n
\"\"<\/a><\/figure>\n\n\n\n
As you can see, ab<\/code> is a single core program. They assume that one CPU core can never generate so much load a web server couldn’t handle. They were proven wrong. While ab<\/code> gasps at 100% CPU, memcp<\/code> bores himself at 767% CPU load while it could take at least 2,300% \ud83d\ude09<\/p>\n\n\n\n
Of course this benchmark does not cover the true memcp<\/code>s performance. For this, the following subsystems have to be implemented first and of course will drag performance further down:<\/p>\n\n\n\n